On Wed, 5 Jan 2011 16:14:00 +0000, Nicholas Clark <nick@ccl4.org> wrote: > OK. *This* also seems to be a failing in the process. In that the process > could and should be that the last approver is *expected* to "cause the > following to happen": Not always. It has at least occurred twice that I was requested to review and approve a specific commit just to enable the first or second requester to do the work described below. Other than that, in my previous workflows this would slow me down a lot. I've now managed to dedicate a cherrymaint session for 30 minutes or more each in which I try to plough through the commits. And I have had one session of actually applying commits, which I picked from all approved but not committed (yet) and that seemed to be in the same mindset (groups like doc-patches, configure-related stuff, tests, ...) > 1: cherry pick the commit > 2: from clean, build > 3: run all tests, which must pass on their platform > 4: push (or rebase and goto 2) > > and if any step fails, report back (how?) and flag the commit (how?) as not > actually ready. 5: cherrymaint mark committed/applied/picked -- H.Merijn Brand http://tux.nl Perl Monger http://amsterdam.pm.org/ using 5.00307 through 5.12 and porting perl5.13.x on HP-UX 10.20, 11.00, 11.11, 11.23 and 11.31, OpenSuSE 10.1, 11.0 .. 11.3 and AIX 5.2 and 5.3. http://mirrors.develooper.com/hpux/ http://www.test-smoke.org/ http://qa.perl.org http://www.goldmark.org/jeff/stupid-disclaimers/Thread Previous | Thread Next