Front page | perl.perl5.porters |
Postings from June 2009
Re: Perl 5.10.1
Thread Previous
|
Thread Next
From:
Rafael Garcia-Suarez
Date:
June 21, 2009 09:02
Subject:
Re: Perl 5.10.1
Message ID:
b77c1dce0906210902v41f750a7ga26e1fc772f5cb9c@mail.gmail.com
2009/6/20 Jonathan Leto <jaleto@gmail.com>:
> I think that releasing Perl 5.10.1 with only this change is very
> valuable to the Perl community, so I went and tried to help it along.
>
> Is this a viable option?
Not really, and I'll try to explain why in detail, and to propose an
alternative strategy.
First, the multiplication and rushing out of releases whenever a major
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 put
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.
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.)
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.
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.
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 use.perl /
perlbuzz / etc.
--
Every old idea will be proposed again with a different name and a different
presentation, regardless of whether it works.
-- RFC 1925
Thread Previous
|
Thread Next