Front page | perl.perl5.porters |
Postings from March 2023
Re: Deprecation doesn't mean we have two release cycles beforethings break.
Thread Previous
|
Thread Next
From:
demerphq
Date:
March 31, 2023 09:25
Subject:
Re: Deprecation doesn't mean we have two release cycles beforethings break.
Message ID:
CANgJU+Vna_xQWcWgdVdkgW=WEcOGsbsczy9BR_RBiy4vN+_fow@mail.gmail.com
On Fri, 31 Mar 2023 at 03:15, Karen Etheridge <perl@froods.org> wrote:
> On Thu, Mar 30, 2023 at 12:20 PM demerphq <demerphq@gmail.com> wrote:
>
>> FWIW, I personally stopped trying to address these tickets. Nobody else
>> seemed to care about them, and many of them relate to "abandonware"[1] and
>> I dont see the point in writing a fix that will never get released.
>>
>> I tried to get Andreas to clarify the rules about releasing fixups to
>> PAUSE/CPAN without having to take ownership of the distribution, but he
>> refused to give me a clear answer[2] so I had no choice but to assume that
>> you can only release something if you take ownership over it, and since I
>> don't wish to take ownership of a module I know nothing about I stopped
>> bothering with BBC tickets that are not traced back to a change I made.
>>
>> I would be a lot more enthusiastic about fixing and rolling releases for
>> these distributions if I knew that PAUSE would accept them. It seems a
>> shame actually, effectively PAUSE policy about ownership discourages people
>> from fixing issues like this. Who wants to spend time fixing a deprecation
>> in a distribution you know nothing about when the author is likely absent
>> and PAUSE will refuse to accept the change unless you take ownership over
>> the module?
>>
>
> The community has had some amount of success over the years in convincing
> some inactive authors to turn over comaint or firstcome permission bits to
> other willing volunteers - there is a documented process for that (send
> emails to the author asking to take over; send emails to modules@perl.org
> documenting the effort), and there have been circumstances where entirely
> absent/unresponsive authors have had their modules granted to other trusted
> community members for the purposes of patching troublesome bugs, at the
> discretion of the PAUSE admins.
>
I dont see anything that requires people to take ownership to get a bug
fixed as a scalable process. The current policies made sense when we were a
thriving and growing community, but these days we are the opposite, a
declining community with more and more unsupported code, and less and less
active contributors to support that larger and larger volume of unsupported
code. Anyone with a business sense knows that those trends are not
survivable in the long term. Sure there are heros like you and Leon and a
few other notables who have stepped up to support a lot of stuff, but the
reality is that you guys don't scale. People like you have only so much
time and bandwidth before you are doing as much as you can without
overloading.
IMO It seems reasonable to assume that if noone is even stepping up
to write deprecation fixes for these tickets then it is even less likely
that someone is going to step up and take ownership of them. Case in point,
the first K of these issues that were filed with us I fixed (in the sense
of creating a patch) within hours of receiving the ticket. Since I stopped
doing so, I have not seen a single case where anyone else provided a patch,
let alone took ownership of the module. The best I have seen is a couple
of cases where someone replied "they use warnings fatal" or something along
those lines presumably with the implication it absolves us from having to
do anything about it. (Which imo it does not.)
I think it would be much better and much more scalable if we had a clear
process based around the dual notion that "code on CPAN should pass its
tests even if that means community involvement in bug fixing" and that peer
review and external bug fixes were a reasonable thing, which allowed people
to contribute as they have time availability, and which did not imply a
long term commitment to help with a short term fix. Lets say we had this
committee, we would patch a distribution, send the patch to the owner.
After 4 weeks of inactivity/no-response (or longer maybe, adjust to taste),
we would roll an "emergency release" to resolve the issue, without an
ownership commitment. The committee would peer review each other and sign
off that the patch was the absolute (within reason) minimal change required
to resolve the issue, and that it did not violate the original authors
"artistic intent" (eg it did not include a complete API refactoring, or
perltidying of the code, or whatever). Such a process would actually
scale, and would mean that contributing fixes was much less likely to be a
waste of time, and thus would make people like me much more enthusiastic
about contributing them. We might even get to the point where people see it
as a game, and try to fix the most BBC tickets in the least in amount of
time. That would be a virtuous feedback loop.
Anyway, the reality is for this latest round of deprecations I have been
the only one who has filed patches to resolve any of the tickets
raised, and when I stopped doing so no one else stepped up at all. That
does not bode well for the existing process.
In addition, the "distroprefs" facility exists, which is a registry of
> patches that can be applied on top of an installation, but I think not many
> people know of it or make use of it, other than Slaven Rezic. I think we
> could probably do better with its documentation and perhaps its usability,
> so I want to look at this at the Toolchain Summit in Lyon at the end of
> April.
>
This is interesting, please share whatever information you have about this.
I have thought about the idea of creating an MCPAN, where the "M" stands
for "maintained", where we simply copy the modules from CPAN and keep
maintained copies of them. In theory it could work, in practice it would
be much better if PAUSE adjusted its policies to reflect the talent
scarcity that our community suffers from at this time. More people have
left CPAN and active Perl dev than are joining it, that means that CPAN is
going to suffer from bitrot, and if the only way to address that bitrot is
to take ownership over stuff then I do not see a lot of people volunteering
to do it. Crowd-sourcing that maintenance on the other hand seems to me to
be a viable way forward.
Yves
--
perl -Mre=debug -e "/just|another|perl|hacker/"
Thread Previous
|
Thread Next