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

Re: Perl 5.10.1

Thread Previous | Thread Next
Michael G Schwern
June 20, 2009 19:57
Re: Perl 5.10.1
Message ID:
Nicholas Clark wrote:
> (Again, if the Perl community had tested this in the *year or more*before
> blead became 5.10.0, it would have been spotted in time.)

I know we're bitter about that, I'm always bitter when bugs slip through my
MakeMaker and Test::More alphas, but rather than looking backwards let's look
forwards.  More importantly, let's not cover Jonathan's proposal in bile that
he didn't cause.

> 1: There would be a lot of stick about "17 months, and that's *all*?"

I think we should just suck it up and take this hit rather than withholding a
critical patch because the people who make fun of Perl will use it to make fun
of Perl.  The important thing is fixing the code.  If we withhold a release
for this reason that's a far worse sin, we're withholding a fix just to try
and look good.  It will do far more damage than a small release will.

Worse, this stinks of fear.  You're being pushed around by the worst elements
of the community.  I don't want to work on a project driven by fear, that
fears their users.  I want to work on a project that delights them.  For every
bitter blogger who snipes at a 5.10.1 bugfix release there will be 100 who are
delighted that critical issue finally got fixed.  That they can finally
convince their admin to upgrade to 5.10.  That there's one less REAL reason
not to upgrade.

> 2: I think it would be unwise - 5.10.0 contains a defective smartmatch
>    implementation that we want to kill before it takes hold. 

This argument has merit, but I think the boat has sailed on that one.  It's
already been a year and a half since release.  People are already using it.
There's nothing obvious in the documentation that says they shouldn't (even if
there is, lots of folks will not have seen it).  It was widely trumpeted as
being a new feature.  Lots of Perl programmers are totally unaware there's an
incompatibility coming.  Let's face it, we're going to break 5.10.0 code.

And that's fine.  We've made that decision and it's a good one.  Point is, a
quick, small 5.10.1 release now isn't going to significantly change that.

>    We have the fixed smartmatch - merge that too.

This will increase the complexity and testing of the release by several orders
of magnitude.  It effectively kills the prospect of a quick critical bug fix

If you have two critical bugs it is better to make a release that fixes one
than to make no release at all.

> As is, currently, this is not the route that Dave wants to take. I'm not Dave.
> It's not my call. If I understand Dave's view correctly, he'd like to triage
> the following bugs before going to RC1:
> So would definitely be helpful to getting Dave to ship 5.10.1 would be to 
> look through that list of bugs, and pick off any they feel able to make
> progress on. Progress includes any of

Hold on.  There's several assumptions here that got glossed over.  They're

First is that there is THE "5.10.1" and that this quick release somehow
challenges that.  This is an artifact of a very slow release process where we
have a huge long ramp up to not just "the next stable release" but to "5.10.1"
(or whatever) and the name becomes significant.

Second is the implication that a quick critical bugfix release will draw
effort away from the larger release.  This implies that Perl development is a
zero sum game.  That there's a finite amount of tuits and we need to carefully
horde them and use them sparingly only on critical projects.  It is not.
People have their own itches to scratch and they will scratch their itches and
not yours.  Try as we might to redirect tuits, its difficult to impossible.
It is better to let people scratch their own itches and direct their tuits
where they like.  In this way the Perl development community will expand,
perhaps not in the direction we want it to, but it will expand.  By
discouraging people from working on what they want to and instead working on
what we want to the actual outcome will be driving new people off.

I understand you're tired and bitter about not getting the help you'd like for
the 5.10.1 release, but trying to redirect brand new volunteers away from
their itch isn't going to help that.  The pipeline which feeds new developers
to p5p is broken and I'd put forth that's part of the reason.

This quick release will draw in new people (such as Jonathan) who have never
done any work before.  What could be more encouraging to newbies than someone
walking onto p5p, proposing a new release and it happens!  Let them run with
it.  Let people get excited.  Let go of the brake.

Looking forward, do we have a list of platforms and compilers which a release
candidate has to be tested on before it can be let go?  If we have that maybe
we can parallelize this release so its not drawing away tuits from you and Dave.

Being faith-based doesn't trump reality.
	-- Bruce Sterling

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