Front page | perl.perl5.porters |
Postings from October 2009
What Does it Take to Make a Maintenance Release?
Thread Previous
|
Thread Next
From:
Nicholas Clark
Date:
October 19, 2009 03:01
Subject:
What Does it Take to Make a Maintenance Release?
Message ID:
20091019100117.GE33485@plum.flirble.org
On Sat, Oct 17, 2009 at 10:43:30PM +0100, Nicholas Clark wrote:
> On Sat, Oct 17, 2009 at 01:44:08PM -0700, chromatic wrote:
> > On Saturday 17 October 2009 13:36:14 Nicholas Clark wrote:
> >
> > > Indeed. Whilst I would love to see small, frequent maintenance releases
> > > after the first of a branch, I'm not going to do it, and I'm not in a
> > > position to cause anyone else to do it. So, I have to assume that it's not
> > > going to happen, whatever I would like.
> >
> > Assume for a moment that we had a ready stream of capable volunteers who could
> > collectively produce a maintenance release.
I forgot to add - I feel it still needs someone to co-ordinate it.
This was one of the reasons why when people offered to "help merge changes"
I politely declined. It wasn't actually going to reduce my workload because
1: I still had to track what was and wasn't merged, and why
(git isn't a silver bullet here, because it can't easily tell you
a: that a patch *has* been merged, but was edited in the process
b: that a patch shouldn't be merged because (annotations)
c: that a patch can't be merged until $n other patches are merged first
2: I still wanted to know what was merged. A release is my reputation on the
line.
Hence I would have had to have double-checked whether I was comfortable
with each merge.
3: There's a people overhead administrating and co-ordinating with volunteers.
4: There's a frustration element if volunteers don't do things.
We did have a distributed approach to writing perl589delta.pod, which felt
decoupled from the merging, but
1: It ran out of volunteers, so only got about 70% of the total done
2: The results still needed significant editing and correcting.
I estimate that it reduced the work for me on that task by half. I'm grateful
for that half - thanks to all the volunteers involved with it.
But it doesn't make the job do itself.
> As to time and commitment - what's needed is a desire to work out the
> underlying cause of what's going on. Most of the bugs that aren't trivially
> fixable take me at least a couple of hours (each) to work out. Likewise,
> reviewing changes (be they patches sent to the list, or changes others
> committed directly) takes time if it's not an area of the code you're familiar
> with. I think anyone doing this would need at least free half-day chunks to
> work on it. Anything less than that, and you risk never finishing.
Debugging skills are relevant, because you can hit showstopper bugs.
For 5.8.9, I remember that after RC1, I discovered a troubling regression -
it wasn't possible to use Devel::NYTProf under tainting.
After a concerted hunk of debugging, I came up with a fix, which (I believed)
addressed the root cause. This worked for my bug, but testing of CPAN modules
by Slaven discovered that this then broke the regression tests for IIRC
Text::Template.
So now, the debugging problem was, were those tests correct, or were they
relying on arguably buggy behaviour? After another hunk of debugging and
thinking, I concluded that the tests *were* valid, hence I had introduced
a regression with me fix, hence had to rethink the fix.
Which did happen.
Hence to maintain the historical quality of our releases, it's likely going
to require the availability of core debugging ability, within the window of
the release period.
Nicholas Clark
Thread Previous
|
Thread Next