|| ||Ricardo Signes <perl.p5p-AT-rjbs.manxome.org> |
|| ||perl5-porters-AT-perl.org |
|| ||Re: Either clear the Unicode air--or make a release-blocker? (was:
Unicode cheatsheet for Perl) |
|| ||Sun, 26 Feb 2012 14:39:55 -0500|
|| ||Article, Thread
* Tom Christiansen <email@example.com> [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
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
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
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.
to post comments)