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

[Graham Percival]

On Wed, Sep 14, 2011 at 12:31:14AM +0100, Trevor Daniels wrote:
> 
> Graham Percival wrote Tuesday, September 13, 2011 2:49 PM
> 
> >Let’s keep git master in ready-to-release state all the time. In
> 
> 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.

For the record, I'm not proposing to remove the 7-day waiting
period for a release candidate.

> I'd be happy with a target of keeping git master in a state
> which builds docs and runs reg tests without error.

git master should never be in that state; quite apart from the
havoc it causes with inexperienced contributors, it makes git
bisect a lot more complicated.

> >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.

I'm not at all certain about that -- but the main point is to have
remote branches.  To take a specific example, Mike and Han-Wen did
a lot of debugging of beam collision code in a combination of git
master and rietveld patches in early 2011.  I am proposing that in
the future, work of that scale takes place on a shared branch in
the public repository.

> >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.

Do I count as a "main developer"?  because I don't know enough git
to do this stuff.

I'm not saying that I can't learn, and if the proposal is accepted
I certainly *will* learn.  But right now I don't have the
familiarity with git to be comfortable with making+merging
branches, with only pushing changes from one branch, etc.
I'm pretty certain that Janek and Phil are in the same situation.
And I wouldn't be surprised if Mike wasn't completely fluent in
branches, either.

With very few exceptions, we're basically treating git like svn.
That's not horrible; lots of great software was written (and is
still being written) with svn.  But I think git+branches can offer
so much more than svn-style git.

> >Developers doing medium-large fixes: examples include beam
> >collisions, music function rewriting, Flag grobs, etc. All this
> 
> This would offer an advantage over Reitveld only if several
> developers were collaborating on a large set of patches.

Yes.  Or if there were a set of patches which required a
relatively large number of patches to be in "ready for release"
state.

> 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.

I don't think it's "quite easy".  I need to find the issue,
right-click on the "download raw patch", type patch -p1 <
~/Downloads/issue-1234.patch, etc.  Whereas if that work was done
in a separate branch, I'd just type git checkout
dev/better-build-system and then I'd have the entire thing --
authors, history, and all.

It's not a *huge* pain to get patches from Rietveld, but that
system doesn't exactly encourage shared work on features until
they're pushed to master.  That's what I want to change -- I think
there should be more development *away* from master.

> 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.

This is certainly possible.  I could easily automate this process,
too.  Actually, regardless of where this proposal ends up, I think
I'll make that a priority for this week.
- 24-hour automatic building of master (make, make test, make doc)
- 24-hour automatic building of dev/staging, followed by
  automatically merging those patches with master

I'll treat them as separate stages because people might still push
stuff directly to master, and it would be good to catch those
problems before trying to build dev/staging.

> But I'd prefer we stick with
> Reitveld and encourage developers to test their patches
> more thoroughly themselves over any of these proposals.

We've been saying "hey guys, test your patches more" for the past
couple of months, though.  My vague impression is that about 20%
of patches fail James' regtest comparison, and 5% fail to even
compile the regtests!

I'm pessimistic about things improving without a more concrete
plan -- I'm reminded of the British police joke (told in North
America) about the policeman telling a robber "stop!  or I shall
ask you to stop again!".  (joke about their lack of guns)

Cheers,
- Graham