Front page | perl.perl5.porters |
Postings from June 2009
Re: Perl 5.10.1
From: Craig A. Berry
June 21, 2009 21:22
Re: Perl 5.10.1
Message ID: firstname.lastname@example.org
On Sun, Jun 21, 2009 at 2:53 AM, chromatic<email@example.com> wrote:
> On Sunday 21 June 2009 00:33:54 Craig A. Berry wrote:
>> Anyone seriously wanting to see 5.10.1 out the door is
>> tracking the maint-5.10 branch, not the 5.10.0 tag.
> By this definition, the current approach which has failed to release 5.10 in
> seventeen months (including addressing an important and embarrassing
> regression detected seventeen months ago) is the only serious (and by
> implication, correct) approach.
Approaches don't release software, people do. One of the reasons it's
important to track the actual maint-5.10 branch (or blead if you want
to stay a few days or a week ahead) is that you would then know what
people have really been doing and the immense progress that has been
made. You would know that the pace of 5.10.1 development has been
accelerating. You would know that new tools and processes have arisen
to meet new challenges in 5.10.x, such as the much larger number of
modules than there were in 5.8.x. You might be aware that there are
1300+ patches already applied since 5.10.0 to what will become 5.10.1,
and it might occur to you that for some people, the performance
regression you are so fond of is much less important than one or a
dozen or a hundred others that have already been applied, or maybe
even some that haven't been submitted yet.
One might become aware while tracking maint-5.10 that it is by
definition the development stream leading toward the next maintenance
release of the 5.10.x branch. Anyone who does any planning will have
been making plans based on that, whether that's packagers or just
people who want to see how their modules will work with the next
release. That is one of the public commitments I was referring to.
Eventually actual knowledge of Perl development processes might lead
you to some understanding of the relationships among branches, such as
the fact that many of the patches currently in the maint-5.10 branch
destined for 5.10.1 have also been pulled back to the 5.8.x branch and
released in 5.8.9. Which means that even if it were possible to
release 5.10.0 + 1 regression fix and call it 5.10.1, you would fix
one regression but potentially cause dozens or hundreds of others for
anyone upgrading from 5.8.9 to this hypothetical 5.10.1. I don't
think upgrading should cause you to lose bug fixes you previously had
-- that kind of negates the meaning of the word "upgrade."
> By further implication, anyone not already
> participating in the current process is not serious and does not care enough
> about 5.10.1.
Newcomers who have something to contribute are welcome, but there's no
greater insult to a newcomer than sending them off on some wild goose
chase that just wastes everyone's time. The pumpking has recently
reported status and confirmed plans, so that really settles what's
going to happen. If anyone wants to help, it's not especially hard to
find the many suggestions that have been made for how to do so.
> Every day that Perl 5.10 is the most recent, most modern Perl release
> *increases* the number of people affected by the performance regression.
> Every day that Perl 5.10 is the most recent, most modern Perl release (which
> includes no warning that the smartmatch semantics will eventually change in
> incompatible ways) further entrenches that broken behavior and ensures that an
> eventual backwards-incompatible release will break *even more* code.
> A *new* volunteer has already done the *very modest* work required to produce
> a 5.10.1 which can address both of these problems *right now*. 5.10.1 could
> be out in a week.
To his credit, Jonathan did not go as far as claiming to have produced
a new release, and I don't think you should put those words in his
mouth. He asked a serious question and got some serious answers. I
certainly hope he sticks around. You should know better than to think
that applying one patch is the same thing as producing a release.
Assumptions that some hypothetical quick, easy release could be done
without distracting from and further delaying the real 5.10.1 are just
> Which public commitments would releasing 5.10.1 with the perldelta warning and
> the performance improvement violate?
I've mentioned some already. You may have heard there is a list of
bugs that need looking at. The list has been posted numerous times.
Do you really need to see the URL again, or was that just a rhetorical