Front page | perl.perl5.porters |
Postings from June 2009
Re: Perl 5.10.1
June 30, 2009 09:43
Re: Perl 5.10.1
Message ID: email@example.com
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
well enough to explain it to non-technical people, this idea sounds
... if there can be multiple, rotating release managers. That social
bottleneck is as much a problem as are the technical bottlenecks.
> But even with a scheduled release policy, there's no guarantee that
> a: the bug would be fixed in the next release
> b: that the next release would happen on schedule
*Guarantee*, no, but there are ways to increase the likelihood of releases
happening on schedule from the current low percentage to something in the 95%
No scheduling practice of which I am aware can guarantee a).