develooper 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
March 31, 2023 08:55
Re: Deprecation doesn't mean we have two release cycles beforethings break.
Message ID:
On Fri, 31 Mar 2023 at 03:24, Dan Book <> wrote:

> On Thu, Mar 30, 2023 at 3:20 PM demerphq <> wrote:
>> 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 answer I gave at that time

And the response I gave at the time is that you aren't a pause admin are

> is the only one possible without upending the entire contract of CPAN
> module ownership, which is singularly enforced by the indexer. If you want
> to change a module and the author is unresponsive there are options to be
> granted ownership without their input. You cannot effect changes on the
> indexed version of a module without ownership
Consider how discouraging it would be to know that arbitrary changes could
> be shipped to unknowing users of your module without the process to ensure
> you're unresponsive and that the new uploader bears responsibility for the
> changes.

You are conflating ownership and maintenance. I think if there were a BBC
committee or something like that signed off on changes there should be no
problem.   You speak in absolutes when the reality is that this is all a
matter of human decision making, and if there was a will to find an
alternative then we could do so. If Andreas wants to change the rules he
can do so, he has done so once already.  I am arguing that he should do so

IMO if we leave the policy as it is these modules won't get fixed, or we
will stop deprecating features.  I don't think either outcome is good for
the language, the community or pause/cpan itself.  Long term it suggests
that a large part of CPAN simply won't build with modern perls,  completely
undermining its value, or that we can't deprecate anything, and that
maintaining old dead code becomes the primary focus of perl development,
which IMO would just accelerate the decline of our community.


perl -Mre=debug -e "/just|another|perl|hacker/"

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