Front page | perl.perl5.porters |
Postings from January 2011
On Wed, Jan 05, 2011 at 05:27:06PM +0100, H.Merijn Brand wrote: > 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. That's why I was careful to use the phrase "cause the following to happen" I meant that by being the last approver one is expected to ensure that the work is going to be done, either by doing it oneself, or by checking that the other person completes it. > 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, ...) I realise that it might cause a slowdown to the person doing the approving. *That* is quite intentional. Because it's moving the slowdown from the single maint pumpking to the approver. > > 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 Well spotted. Nicholas ClarkThread Previous | Thread Next