lilypond-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Q: patchy-test and patchy-merge


From: Graham Percival
Subject: Re: Q: patchy-test and patchy-merge
Date: Sun, 5 Feb 2012 11:19:19 +0000
User-agent: Mutt/1.5.21 (2010-09-15)

On Sun, Feb 05, 2012 at 10:57:59AM -0000, Phil Holmes wrote:
> My current patchy understanding of patchy is that patchy-merge runs
> make and make test, and if these are OK then it pushes staging to
> master.

and make doc.

The overall point of staging-merge is: if we include all those new
commits, will anybody get a build failure?

> AFAICS from the code, it requires quick_make=True to do a
> doc build and regtest comparison, and this is false for the normal
> run.

You're confused because the badly-named
def main(...)

should actually be called
def test_patches(...)
or something like that.

For the staging-merge, look at handle_staging.  PS your hint for
this was that you run lilypond-patchy-staging.py, *not*
compile_lilypond_test.py directly.


If somebody spent maybe 30 minutes reading this code carefully and
fixing a few variable and function names, it would be easier to
read.  Sadly, I've already spent 1 hour of next weeks' time, so
I'm probably not going to have any time until mid-Feb.


> It's the job of patchy-test to check that a patch is OK to consider
> for pushing to staging, and this includes make doc and a regtest
> comparison.

I would say: its' the job of test-patches.py to prepare a regtest
comparison for a human to quickly glance at, which will determin
if the patch is ready for a *review*.  This does not include make
doc.

Basically, we don't want to waste reviewers' time looking at
patches which do not apply to master, or fail to compile, or have
huge regtest faults.  If a patch has a compile failure, it should
be automatically rejected (the automated part of this isn't
happening yet).

> So the process flow should be: patch goes for review.  It should be
> reviewed by relevant devs

No.  No relevent dev should waste time looking at any Patch-new
items.  If Patchy test-patches.py hasn't said the patch is ok, no
developer looks at it[1].


[1] of course if there's a "work in progress" patch that somebody,
particularly a Frog, wants attention from, there's no problem
sending a link to -devel and asking for help.  But those patches
should be clearly understood to be "work in progress", aka
"broken", aka "not a candidate for pushing".

> It's pushed to staging and gets the less
> rigorous testing from patchy-merge but sufficient to ensure make is
> (almost) guaranteed to work on master.

Yes.

- Graham



reply via email to

[Prev in Thread] Current Thread [Next in Thread]