develooper Front page | perl.perl5.porters | Postings from January 2011

Re: let's be stricted with maint doc changes

Thread Previous | Thread Next
Nicholas Clark
January 4, 2011 00:55
Re: let's be stricted with maint doc changes
Message ID:
On Tue, Jan 04, 2011 at 03:24:47AM -0500, Jesse Vincent wrote:

> On Tue, Jan 04, 2011 at 09:12:22AM +0100, Abigail wrote:

> > Typo fixes and many other documentation improvements seems low hanging,
> > non-dangerous fruit to me. I'd prefer them to be part of a maint release.

Fixes other than typos can be dangerous, if they aren't relevant to (or
contradict) behaviour in the maint branch. So they do need checking.

> That is how the policy was written after a fair amount of lobbying at
> me.  I now regret it.  The problem isn't whether it's low-hanging fruit
> or not. The problem is that each patch adds somewhere between 5 and 15
> minutes of release-engineer load over the life of the release process.
> 25 simple doc fixes quickly start to add up, slowing down the release
> and taking focus away from other things that Must happen.

When I was doing maint releases I was keen to have them. *But* I was the
person choosing to slow myself down.

Also, I was (at least subconsciously) aware that the release of 5.10 seemed to
be consistently "not happening yet", so any changes in blead "didn't exist",
as far as most of the world was concerned, and I was keen to get them out.

This, I believe, changes, now that we have clear desire and commitment to
make regular new stable releases of blead yearly. Before, distribution
upgrades seemed to be from 5.8.$older to 5.8.$newer, so (clearly) doc fixes
need to be merged to become visible. I suspect now we're going to see
distributions upgrade from 5.$older.something to 5.$newer.something.
Yearly stable releases from blead are the new $mumble-monthly stable releases
on maint.

> 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?

Nicholas Clark

Thread Previous | Thread Next Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at | Group listing | About