Home
Reading
Searching
Subscribe
Sponsors
Statistics
Posting
Contact
Spam
Lists
Links
About
Hosting
Filtering
Features Download
Marketing
Archives
FAQ
Blog
 
Gmane
From: Ricardo Signes <perl.p5p <at> rjbs.manxome.org>
Subject: Re: Either clear the Unicode air--or make a release-blocker? (was: Unicode cheatsheet for Perl)
Newsgroups: gmane.comp.lang.perl.perl5.porters
Date: Sunday 26th February 2012 19:39:55 UTC (over 5 years ago)
* Tom Christiansen  [2012-02-25T17:28:42]
> We should not have to endure five more tedious years of people getting
> tonguelashed and flamenagged into writing horribly complicated code
> all because something deep down in Perl's dwimmer is flawed.
> 
> I say five years, not one year, because of how long it takes to get
vendors
> to get themselves updated.  If this is a legit issue, and we push it off
till
> 2013's v5.18, then it will be a further 2–4 years past that until
people can
> have reasonable Unicode processing in their vendor Perl.  That puts us
into
> the 2015–2017 (!) time frame, and... that's just not acceptable, eh?

This argument does not persuade me.  It makes several unstated assumptions
which, I think, do not stand up.  Aristotle mentioned one, regarding the
fact
that the real delay here is one year.  If the worst case after a year's
delay
is five years, and the worst case after no delay is four years, we're still
talking about one year's difference.

But that isn't the thing that I think needs to be addressed.  The thing
that
needs to be addressed is the very notion that we can ship 5.16.0, with this
fix, in 2012, without other undue complication.

If I were to stand on a tall rock and shout, "No 5.16 will ship until this
checklist of unicode bugs is addressed!"  How long would it take to get the
release cut?  No one can say, because there is no stable of programmers to
assign to the task.

I suggest that every programmer who wants to see this fixed is already
working
on it to an extent proportional to his or desire to see it fixed.  I
suppose
there is some room to imagine that were this to block 5.16, others might
turn
their attention, just because they are interested in seeing *other*
features of
5.16 see a "stable" release, but I think the chances of this are low.  I'd
also
rather not comment on the quality of the work we'd get from that kind of
pressed labor.

I think the subthread that continued, talking about timeboxing of releases,
ended (at my last glance) with an unfair characterization.  5.16.0 is not
to be
released "no matter what" as some arbitrary snapshot.  That is, I don't
plan to
wake up on a beautiful April day and press a button that will package and
ship
the latest commit on blead as 5.16.0.

There is a process for testing for stability of blead, and for testing
whether
existing code is broken by it, and for establishing what bugs should block
releasing 5.even.0.  We don't want to ship regressions, or to break "half
of
CPAN," or release with insufficiently documented changes, or so on.  That's
why
we forcibly slow down changes to features and core libraries as we approach
the
landing strip.

It's definitely true, though, that 5.even.0 releases *are no longer
milestones.*  Or, rather, they are milestones in a much more literal sense
than
is often meant.  5.16.0 means that we've come about one year since 5.15.0. 
It
does *not* mean that we have met a series of goals named at 5.15.0, for
example.  

It may just be the case that we can have these problems all addresesed
(say)
this summer.  If that happens, and if we judge it to be of sufficient
importance, we can even issue 5.18.0 early as "5.16.x + those changes." 
This
would be disruptive, but it would be a disruptive with a clear and
achievable
goal.  Delaying now would be an indefinite delay with no resources to
allocate
toward the problem.

As an aside:  Tom, thanks for your summation of the specific issues.  I am
always really grateful for your messages of this sort, as they tend to be
both
clear and comprehensive – a rare combination.

-- 
rjbs
 
CD: 4ms