Graham Percival wrote Tuesday, September 13, 2011 2:49 PM
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.
Hhm. Not sure about ready-to-release-a-stable. I think we need warning when a new stable is to be built. It is inevitable that new code will contain bugs which will only be found when users of development releases run real music through them. This takes time, so I'd prefer to have a period prior to building a stable in which major changes were discouraged. I'd be happy with a target of keeping git master in a state which builds docs and runs reg tests without error. That is, no incomplete patches should be pushed.
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.
Tick
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.
I'm pretty sure most developers do their work in separate branches anyway, albeit on local branches.
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.
Again I'm pretty sure all main developers already have a good familiarity with git.
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.
This would offer an advantage over Reitveld only if several developers were collaborating on a large set of patches. It is quite easy now for anyone to download a patch from Reitveld to check it compiles, runs the reg tests and builds docs successfully. James already does this for the reg tests. All we need to do is formalise it, so large patches are not pushed to master unless and until James (or whoever is willing to do this work) has given approval. If git itself is to be used I think it would be better to have a single "staging" branch in which patches could be placed prior to merging into master. The reg tests and doc builds could then be run just once prior to merging, rather than separately on each patch. But I'd prefer we stick with Reitveld and encourage developers to test their patches more thoroughly themselves over any of these proposals.
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.
Tick. It also means we don't get caught out with problems caused by not rebuilding the fonts after such changes, as the need for this would be more clearly signaled than at present. Trevor _______________________________________________ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel