Front page | perl.perl5.porters |
Postings from January 2011
Re: let's be stricted with maint doc changes
Thread Previous
|
Thread Next
From:
Nicholas Clark
Date:
January 5, 2011 08:14
Subject:
Re: let's be stricted with maint doc changes
Message ID:
20110105161400.GN24189@plum.flirble.org
On Tue, Jan 04, 2011 at 08:32:06AM -0500, Ricardo Signes wrote:
> * Nicholas Clark <nick@ccl4.org> [2011-01-04T03:54:55]
> > > I'm not ok with this idea. maint releases need to be as conservative as
> > > possible. Part of making sure that happens is by requiring some checks
> > > and balances before backports happen. Opening up maint for doc
> > > backports without running through the process runs directly counter to that.
> >
> > Agree. However, there are more people qualified to review (and backport)
> > doc patches. So in theory, if a sufficiency of volunteers volunteer, their
> > part of the work takes care of itself without slowing others down. But, you've
> > done it you way - I haven't. Were you finding that all patches were "equal",
> > in that a doc patch potentially took as much of your time as a C code patch?
>
> Here's some anecdotia.
>
> I've come across a number of "approved" commits that are not actually
> cherry-picked. It seems to me that if the commit is approved, and I'm going to
> do the next release, I should pick it. So, that adds time -- three people
> wanted the commit, but not enough to pick it, so I will. Then I find out that
Well, yes. In which case they didn't actually want it.
> it won't actually apply cleanly. A previous commit, possibly only seconded but
> not approved, is required. So I review that and pick it to apply, then go back
> to the approved commit. Then I find that tests fail, because there's now a Pod
> syntax error, which is fixed in later, not-even-requested commit.
>
> This takes *much* longer than C code patches, which I ignore entirely.
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":
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.
Because those steps don't need to be done by the maint (release) pumpking,
so it's wrong to increase the workload of a single-point-of-failure, where
that workload could be distributed.
*And*, by implication, if people aren't comfortable to actually do the above
3 steps, then I'd argue that they aren't actually comfortable with that
patch going to maint, so it shouldn't go.
(Yes, this viewpoint might be seen as somewhat trolling, but if we're going
to distribute the processes, we need to distribute the process *properly*,
not in some lip-service fashion)
Nicholas Clark
Thread Previous
|
Thread Next