Front page | perl.perl5.porters |
Postings from September 2016
* Kent Fredric <kentfredric@gmail.com> [2016-09-22 20:48]: > On 22 September 2016 at 21:21, Abigail <abigail@abigail.be> wrote: > > when the deprecated ones are scheduled to be > >> removed, or that there is no current plan to remove them. > > > > I think we should eliminate the latter category. > > Disagree. That category mostly exists because we shouldn't be removing > things "just because". I agree with the justification but not the conclusion. We can and should still eliminate that category. I continue to advocate that we scale down all long-standing still-indefinite deprecations to discouragements. That is effectively how they were intended anyway; that distinction only came about long after many of them were deprecated. People don’t like the suggestion because per a legalistic interpretation of the policy, already-deprecated features could be removed without an extra deprecation cycle – at least in theory – whereas scaling them back to discouragements would require an extra deprecation cycle if they ever were to be removed. Then, inevitably, the discussion fizzles out, and nobody even reviews any of the deprecations, so they just continue to stick around as long- standing indefinite deprecations for years down the line. So the bottom line in practice is that p5p retains liberty to remove them quickly at some hypothetical point in the future, at the cost of clarity for users in the meantime. Clarity for users, of course, is the whole point of having a policy. If it’s just there for the benefit of developers seeking to feel justified in their actions, without helping users evaluate their situation, then it’s just window dressing. I would like it to not be window dressing. My line of argument is further reinforced by the fact that if we were to actually try to remove long-standing indefinitely deprecated features, many of them will probably cause too much breakage to actually remove on the theoretically/legalistically possible accelerated schedule. So these will effectively end up running on the same schedule as if they had been scaled back to discouragements. Then the only difference is in how clear their status is to users in the meantime. And a final flank is that if we are serious about the policy as laid out in the document – which is not to remove things before they actively get in the way – then a push to carefully review the status of long-standing indefinite deprecations will merely end up scaling most of them back to discouraged *anyway*. So we should do users a favour and just go with that. Regards, -- Aristotle Pagaltzis // <http://plasmasturm.org/>Thread Previous | Thread Next