sorry, I forgot to send this on Wednesday. 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 _______________________________________________ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
