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

Re: Perl 5.10.1

Thread Previous | Thread Next
David E. Wheeler
June 21, 2009 20:26
Re: Perl 5.10.1
Message ID:
On Jun 21, 9:02 am, (Rafael Garcia-Suarez)  

 > First, the multiplication and rushing out of releases whenever a  
 > fix is committed in not desirable:
 > 1. From a project management point of view, we're squeezing a release
 > between the last release point and the tip of the maintenance branch,
 > effectively multiplying tips, and thus multiplying effort. Why not  
 > innocent doc patch there too, for example? The slowness of release of
 > maint shall not be remedied to by multipling the number of maint
 > branches -- the number of maintainers is too low. This goes obvious
 > when said.

Then we need more maintainers. The way to get more maintainers is to  
release more often, with an automated release process. Sure there's a  
chicken-and-the-egg problem here, but it starts to be solved by the  
act of one egg. Surely there are enough eggheads on this list to make  
it workable! ;-)

Also, why should a new minor release add a new tip? Are there not back  
branches for the minor releases, with master/trunk/whatever designated  
for 5.12? Why should a new release multiply the number of release  

 > 2. Perl 5 version numbers are not cheap. They correspond to more
 > subdirectories in @INC (and more stat calls to find modules), to more
 > versions to install for the CPAN authors and testers, to more space
 > and time on the smoke matrices, to more entries in Module::Corelist.
 > They also correspond to more hassle for OS packagers, with the
 > subdirectory layout changes (been there.)

If minor releases are binary compatible, why should this be so? And  
for those silly platforms that choose to do that, so what? I had 8  
such directories for 5.8.8 and never complained, because things were  
improving rapidly (every 3 months for a while!). I don't think most  
folks really worry about the stat calls, that's hardly the slowest  
thing in Perl. And I suspect that the CPAN testers will be the last to  
complain if there are regular new releases of Perl with bug fixes.  
Hell, a bunch of them run bleed anyway.

 > 3. Yes, there's been a long time between 5.10.0 and .1 : the first
 > maint release after a .0 seems to take more time because the code is
 > less stabilized. Also, a new pumpking started, and a new VCS was put
 > in place. We'll hopefully have in the future much closer releases,
 > like what Nicholas did for 5.8.x.


 > Having a tool to help many people
 > cherry-picking patches to maint concurrently would also help
 > unbottlenecking the process.

Git should help with that.

 > However, we haven't failed at releasing quickly security patches in
 > the past, and we do have also a documented process to build perl with
 > a given set of patches, and make them reported by "perl -V". And if
 > you look at the perls distributed by RedHat, Debian, FreeBSD,
 > ActiveState, and a lot of other systems, you'll see that they have
 > many patches in there.
 > So, what we seem to need is, actually, a way to quickly bless,
 > distribute and advertise a small number of important patches.

Which no one will actually run. People run release, not patches.  
Otherwise, why release at all?

 > I would suggest to maintain a list of important patches (with the
 > vendors). Git is a useful tool to release them. A ML could be created
 > to advertise them, but who cares about MLs nowadays? We would need to
 > advertise them as well 1. officially on, 2. on  
use.perl /
 > perlbuzz / etc.

I think that this will work with only the geekiest of Perl hackers.  
You know, those of us on Perl 5 porters already (okay, so I just re- 
joined for the first time in years, sue me! ;-).

In all honesty, I'd love to see far more frequent releases. Any  
technical barriers to such releases should be removed, IMHO.



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