Re: Perl 5.10.1

Front page | perl.perl5.porters | Postings from June 2009

Thread Previous | Thread Next

From:

Nicholas Clark

Date:

June 30, 2009 11:18

Subject:

Re: Perl 5.10.1

Message ID:

20090630181809.GJ33745@plum.flirble.org

On Tue, Jun 30, 2009 at 09:43:15AM -0700, chromatic wrote:
> On Tuesday 30 June 2009 09:35:56 Nicholas Clark wrote:
> 
> 
> >    What I'm thinking might be best is having planned interval*s* to code
> >    freezes for the maintenance branch. This is assuming that all bug fixes
> > get into blead by someone-not-the-maint-pumpking, as has roughly been
> > happening since 2003. Merging (cherry-picking) is assumed to run in
> > parallel, with a minor lag to assess stability in blead. (Or whichever
> > branch is the integration and "please CPAN smoke this")
> >
> >    So, 1 month after 5.14.0 is shipped is the cutoff to get fixes into
> > blead for 5.14.1-RC1. 2 months after 5.14.1 ships is the cutoff to get
> > fixes into blead for 5.14.2-RC2 etc.
> >
> >    This would mean releases at 1, 2, 3, 4, 5 and 6 months (then steady
> > state at 6 months, or possibly even go to "build fixes and security issues
> > only), which is 6 releases across 21 months, rather than 7 quarterly, but
> > with releases concentrated where it matters more.
> 
> With the caveats that release candidates are a polite fiction that do not work 
> in practice and that few outside p5p will be able to understand this schedule 
Oh, I think that they work very well for a couple of fringe benefits that
may not be obvious

1: Release manager's peace of mind. If $person finds a bug in in a release,
   then I blame myself. Well, until I've checked whether it was also present
   in the release candidate, and if so, I don't blame myself any more.
   (And there may well be a reply to the bug noting that the issue was in the
    release candidate, and if in future they might be able to test future
    release candidates, they would mitigate this. *Yes*, they can ignore this
    request. But at that point, it's 100% their fault. And I don't feel bad.)

2: In the same way that everyone assumes that someone else will install
    anything.0, such that .1 will be the new .0, and even 2.0 will be the new
    1.0, it seems that few to no-one gets the hint that it would be good to
    test a *snapshot* against their code.
    At least calling something release candidate scares a few people into
    actually testing it. Few is better than zero, which is what seems to happen
    otherwise.

> well enough to explain it to non-technical people, this idea sounds 
> workable...

I think if it's "about 1 month, about 2 months, about 3 months" it will
work well enough.

But, again, I declare that I've retired from doing releases, so if people
want this, they're going to have to volunteer themselves, volunteer their
companies resources, pay a third party firm to do this, or self-organise
into a collective to recruit and retain paid staff to do it.

That list might not be exclusive, but to me those are the 4 most obvious ways
to "make it so"

Nicholas Clark

Thread Previous | Thread Next