branching

[Mike Solomon]

Hey all,

As 2.18 draws near, I’d like to work with everyone to establish a system of 
branching for LilyPond development.  After several rounds of discussing things 
with David K, this emerged as the best way to avoid arguments about integrating 
work into the development branch that have led several contributors, including 
myself, to significantly reduce time on the project. [1]  I feel that this 
reduction in commit diversity is the biggest obstacle to LilyPond’s future 
evolution, which is why I’m calling on everyone to make a concerted effort to 
think this through.

There seem to me to be two main issues to sort out in doing this:
** how to get developers into the habit of working on separate git branches
** how to get users using these branches

I have opinions about both, which I will state below.  After some go around, 
I’d like to see something written up as a community-endorsed proposal that 
would then be implemented by myself and whoever else wants to help me out.

** how to get developers into the habit of creating separate git branches

Several developers would create development branches, i.e. devel-dk, etc.. 
These branches have no theme other than their being the principal sandbox of a 
particular developer or group of developers.  There would also be a devel-jd 
for John Doe, meaning anyone who does not have their own branch.  All of these 
branches would track staging.  We would limit the number of these branches to 
around 5.  Work on staging would then consist _only_ in merging these branches 
(or cherry picking commits from them) to staging.  These merges would be 
regular, part of the countdown cycle and discussable.  Patch review would exist 
just as now, except that “push” means that things get pushed to one of these 
branches instead of to staging.  Developers who don’t know how to use git’s 
branch features would be given help by those who know how.

** how to get users using these branches

On the website, we would offer _all_ of these development branches, including 
the one built off of staging, as GUB builds.  We would also contain a tracker 
showing number of downloads and encouraging users to download the branches that 
have been downloaded the _least_.  This would allow us to ensure that all 
branches are being tried out.  On the website, developers could also request 
that certain users use certain branches.  For example, if I were doing a lot of 
lyric work, I would ask on the website for people frequently using lyrics to 
use my branch.

I’m looking forward to hearing everyone’s ideas on this.

Cheers,
MS

[1] Development branches should not be construed as a substitute for collegial 
communication in our community, irrespective of the degree of difference 
between any of its members.