Re: [O] Thanks for Lilypond export (and minor comments)

[Bastien]

Hi Suvayu,

thanks for sharing this suggestion and to make it so clear.

I understand the model you describe and I see why it's appropriate for
projects like "git" -- as IIUC, your proposal is very close to the one
described by git's maintainer.

Let me summarize my ideas about how we should use git for Org.

I have three principles.

(1) git should reduce maintainer(s)'s work
(2) git should let more developers submit patches
(3) git should ease collaboration on fixes and new features

I put them here in priority order.

Yes, it means that I'm more interested in being lazy than in having more
patches, and in having more patches than in easing collaboration between
developers.

I think it works so far for three reasons:

- I'm not *that* lazy :)

- The latest git HEAD is stable enough so that many people live on it,
  and can send feedback on patches.

- Contributors rarely need to collaborate on fixes and features and when
  they do so, they collaborate by discussing on the mailing list.

More branches (master, maint, feature-1,...) means more _incompressible_
work for the maintainers, even when they are ninjas of the git Three Way
Merges.  This additional work is only worth undertaking when people are
*really* using the branches to collaborate -- which is quite unlikely to
happen given the three reasons above, and also given the fact that the
release pace of stable versions is quite fast.

Last but not least, sticking to the current usage of git (i.e. commit
into master as much as possible, commit only to maint for bugfixes that
need to be released independantly) doesn't prevent using public branches
from time to time -- we did it with Julien Danjou before.

Hope it helps understanding my approach!

It's all based on the idea "if it works, don't break it".

But I'm open to any change if (and when) we need it.

Best,

-- 
 Bastien