Front page | perl.perl5.porters |
Postings from June 2009
Re: Perl 5.10.1
From: David E. Wheeler
June 21, 2009 20:26
Re: Perl 5.10.1
Message ID: 5E7D41CA-D3A5-4AD3-82A6-AB7F86CF3077@kineticode.com
On Jun 21, 9:02 am, rgarciasua...@gmail.com (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 dev.perl.org, 2. on
> 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.