develooper Front page | perl.perl5.porters | Postings from April 2016

Re: perl v5.24.0 blockers, March 22 edition

Thread Previous | Thread Next
Aristotle Pagaltzis
April 7, 2016 18:38
Re: perl v5.24.0 blockers, March 22 edition
Message ID:
* Ricardo Signes <> [2016-04-01 14:30]:
> Yes, thanks. I agree (if I understood!) that what we want to do, in
> these situations, is to encourage the other parties to let us know
> what they think of the situation. Do they, too, believe that they were
> making unwarranted assumptions? If so, do they want some help with
> making things work anew? If not, how will we proceed?

I believe the issue is even bigger than this rephrasing makes it out to
be. Scope::Upper has users – asymptotically all of which are unable to
answer the question of whether it was making unwarranted assumptions,
who for that self-same reason they are all the more dependent on it.

So even if both p5p and its author eventually agree that its assumptions
were unwarranted, that doesn’t implicitly make breaking it OK: there are
still lots of people who need it to continue to work.

And that circle is potentially very wide. It is already wide on CPAN due
to transient dependencies. But it reaches far beyond, because a user may
just be someone who installed an OS package that happens to have been
written in Perl.

An author may have made the unwise decision, but the users, all along
the entire downstream, almost all unable make a judgement about their
participation author’s decision (if they’re even aware), are the ones
who will be receiving the punishment for that.

This is not an argument against ever fixing/improving anything. It’s an
argument for ensuring continuity. It’s harder than just breaking things
blithely but it’s *not* impossibly onerous. All it requires is to accept
the challenge that it can be done.

And a date on a calendar means little to me. If the release slips for
months, it’s not going to bug me. At most it’ll bug me during the wait,
and will be forgotten right afterwards.

Whereas it continues to bug me to this day that Coro is broken. [^1]

Now the situation is a bit different this time around. The changes that
break Scope::Upper are much more worthwhile than the “improvement” that
we got in exchange for a broken Coro.

But the point remains that missing a date is really unimportant in the
longer scale of things. If it’s the timeboxing you worry about, then
compensate for it by merging only a smaller number of probably safer
patches afterwards and ship another release quickly to catch up to the
groove again.

The desideratum of timeboxing isn’t the date on the calendar. It’s to
take the pain out of “this work will have to wait for next release” as
much as possible, so that the release doesn’t keep slipping as people
try to cram more into it because who knows when another chance to get
the work out there will come along. And that’s true *particularly* when
the release slips for *substantial* reasons.

[^1]: No, I don’t blame that on its author.

Aristotle Pagaltzis // <>

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