GOP-PROP 12: keep master in ready-to-release state

[Graham Percival]

I decided to bring this proposal forward earlier than initially
planned.
http://lilypond.org/~graham/gop/gop_12.html


** Proposal summary

Let’s keep git master in ready-to-release state all the time. In
particular, assume that git master could become the next major
stable release at any time. If that makes you pause and wonder if
you should really push a particular patch (because it would leave
something hanging or unfinished), then put that on a separate
branch and/or upload to rietveld instead of pushing to master.

In addition, modifications which change a lot of output (such as
fonts or spacing tweaks) could be “saved up” and applied in a
special release which only contains those.


** Rationale

Git is a wonderful tool for source handling, but we’re only
scratching the surface of what it can do. It might be good to have
all active development working on separate branches.

This could reduce the pain of git master getting broken from time
to time – if everybody worked on separate branches, and those
branches were only pulled to master when it compiled correctly,
then master would never be broken! In theory, at least.


** Pain of learning git

This proposal would require that all main developers have more
than basic familiarity with git, but I think there’s enough help
out there – I’m particularly impressed by the tutorials on
http://github.com.

More discussion about the workflow here:
https://lists.gnu.org/archive/html/lilypond-devel/2011-09/msg00185.html


** Proposal details

Beginning Frogs: no change. They can’t push to master anyway; the
Frog Meister will make sure that each change is "complete" before
pushing to master.

Advanced frogs attempting huge changes: we’ll sort something out,
quite possibly using a fork on github. (seemed to work here:
https://github.com/aspiers/lilypond)

Developers doing small fixes: no change.

Developers doing medium-large fixes: examples include beam
collisions, music function rewriting, Flag grobs, etc. All this
work should go on separate branches (e.g. dev/flag-grob,
dev/scheme-music-functions). Once the code is merged, the branch
should be removed. People can still use dev/myname instead, but I
think that naming these branches after the feature (or bugfix)
will be more clear.


** “font” release

The existance of massive-change patches is problematic; a tiny
modification to some font can cause almost every regtest to show a
change. We could consider "saving up" those patches, then having a
release which only includes those patches. A cursory examination
should suffice to see that nothing has broken. At the current rate
of releases and patches, I’m envisioning having a "font release"
once every two months.

This would require that those patches be stored in a separate
branch and only merged with master at the appropriate time.

** Implementation notes

None yet. 


Cheers,
- Graham