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

[Trevor Daniels]

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