* 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
> to get themselves updated. If this is a legit issue, and we push it off
> 2013's v5.18, then it will be a further 2–4 years past that until
> have reasonable Unicode processing in their vendor Perl. That puts us
> 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
that the real delay here is one year. If the worst case after a year's
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
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
on it to an extent proportional to his or desire to see it fixed. I
there is some room to imagine that were this to block 5.16, others might
their attention, just because they are interested in seeing *other*
5.16 see a "stable" release, but I think the chances of this are low. I'd
rather not comment on the quality of the work we'd get from that kind of
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
released "no matter what" as some arbitrary snapshot. That is, I don't
wake up on a beautiful April day and press a button that will package and
the latest commit on blead as 5.16.0.
There is a process for testing for stability of blead, and for testing
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
CPAN," or release with insufficiently documented changes, or so on. That's
we forcibly slow down changes to features and core libraries as we approach
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
is often meant. 5.16.0 means that we've come about one year since 5.15.0.
does *not* mean that we have met a series of goals named at 5.15.0, for
It may just be the case that we can have these problems all addresesed
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."
would be disruptive, but it would be a disruptive with a clear and
goal. Delaying now would be an indefinite delay with no resources to
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
clear and comprehensive – a rare combination.