Re: PATCH: Countdown to 20111027

[Graham Percival]

On Wed, Oct 26, 2011 at 07:04:48AM -0600, Colin Campbell wrote:
> Procedurally, I gather that the patch meister doesn't really care
> whether a patch is on /staging or /master, only that Patchy has
> checked it, and that there are no howls of protest in the discussion
> on Rietveld or the various lists, before marking it for countdown,
> and eventually for pushing.

Yes, but the patch should not be on either /staging or /master
until after the countdown.

> However, the first point above is
> ambiguous: if a patch only gets to staging by way of a countdown,
> then wanting it pushed immediately is moot.

Yes-ish.

Basically, the idea is that we forbid anybody from pushing to
master.  Work flow is this:

- pull from master.
- start editing files.
- commit changes, upload to rietveld, optionally push to a
  dev/whatever branch
- reviews, countdown
- push to dev/staging
- patchy compiles dev/staging, makes sure it doesn't die, and then
  merges dev/staging to dev/master.

The idea is that we should NEVER have a broken master.  Whenever
somebody checks out lilypond git, they should be able to compile
it.  (I know that you've had a lot of pain running into broken
stuff on master)

> I had the impression that staging was for potentially disruptive
> patches, those which might cause large-scale weeping and
> wailing, and so should go into a sort of extra sanity check
> before going onto master.

No.  dev/staging is for any patch that wants to go to master.  I'm
not going to insist on this... but rather, if somebody pushes
something to master and it breaks, I will yell at them.

Some people are extremely reliable about only pushing well-tested
patches.  Other people are generally reliable but occasionally
slip up and/or don't mind a delay of 12 hours.  Some people have a
habit of pushing broken patches, or patches that did work but they
made "one last change" which broke stuff.

I want the latter group to ONLY push to dev/staging.  The former
groups can either use staging or push directly to master, as long
as they accept the risk.  Other than the extra pain of git, there
is no downside to pushing to dev/staging instead of master.

> Given that the Bug Squad verify patches with current GUB, can we
> label patches which are fixed in /staging differently from those
> which are fixed in GUB, so that a patch marked "fixed" is assumed
> *not* to be in the GUB build?  This might be a developer error,
> simply forgetting to update the tag, but it could also mean the
> patch is not yet in the publicly available rele4ase.

that is a concern, but I have no energy left to be concerned about
it.  Note that merging from dev/staging to master will be
completely automatic (including the tests to determine if this is
safe).  hmm, I suppose you could add a "staging" tag to google
code, then patchy could automatically remove any "staging" tag
when he merges it.  Although there's a potential for
"multi-processing" scheduling flaws; if somebody pushes something
to staging after patchy starts testing it, he'd still remove that
"staging" tag.

I don't think it's a huge issue.  If staging can't merge, we'll
have a big wailing and gnashing of teeth, so we're not going to
lose those patches.  And I'm not going to make a release while
we're in the middle of staging-wailing-gnashing.


The most important thing, in my mind, is to stop the idiotic
breaking git master once a month that seems to be our custom.  We
should never have new contributors trying to build lilypond and/or
the docs and have the compile break.

- Graham