Front page | perl.perl5.porters |
Postings from April 2016
* Ricardo Signes <perl.p5p@rjbs.manxome.org> [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. Regards, -- Aristotle Pagaltzis // <http://plasmasturm.org/>Thread Previous | Thread Next