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
Diab Jerius
March 31, 2023 15:49
Re: Deprecation doesn't mean we have two release cycles beforethings break.
Message ID:

On 3/31/23 04:55, demerphq wrote:
> 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 you?
>     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.

In the Debian world these are called NMUs, Non-Maintainer-Uploads, and 
as with all things Debian, there’s a policy around them:

Perhaps some of that is applicable here?


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