Mailing List Archive

On Mon, Feb 27, 2023 at 11:17:02AM +0100, demerphq wrote:
> But that isn't correct. Odds are *very* likely we get CPAN breakage from
> the very moment we deprecate something

+1

I'm particularly troubled that we have added two major deprecations
very late in this release cycle:

5.37.9: deprecate Foo'Bar
5.37.10: (not even released yet): change 'experimental' to 'deprecated':
~~, given, when, etc.

There seems to have been a lot of CPAN test suite breakage from these.
Even if the fixes turn out to be trivial, and even if p5p volunteer to do
all the fixing, it doesn't leave a lot of time to get new releases out and
settled in.

So I think that
a) such deprecations in future should only come early in the blead release
cycle;
b) we should seriously consider backing out for now the two specific
Foo'Bar and ~~ deprecations and re-adding them for 5.38.1.

--
Never do today what you can put off till tomorrow.

On 2023-03-01 6:11 a.m., Dave Mitchell wrote:
> I'm particularly troubled that we have added two major deprecations
> very late in this release cycle:
>
> 5.37.9: deprecate Foo'Bar
> 5.37.10: (not even released yet): change 'experimental' to 'deprecated':
> ~~, given, when, etc.
>
> There seems to have been a lot of CPAN test suite breakage from these.
> Even if the fixes turn out to be trivial, and even if p5p volunteer to do
> all the fixing, it doesn't leave a lot of time to get new releases out and
> settled in.
>
> So I think that
> a) such deprecations in future should only come early in the blead release
> cycle;
> b) we should seriously consider backing out for now the two specific
> Foo'Bar and ~~ deprecations and re-adding them for 5.38.1.

I will assume you meant to say 5.39.1 here.

-- Darren Duncan

On 2023-03-01 6:11 a.m., Dave Mitchell wrote:
> b) we should seriously consider backing out for now the two specific
> Foo'Bar and ~~ deprecations and re-adding them for 5.38.1.

So IF either or both of these are backed out as you say, I feel it would still
make sense to update the 5.37.x/5.38 documentation somehow to say that they
should be considered deprecated now and only weren't formally made so in 5.38
because of the fatal warnings / etc concerns. -- Darren Duncan

On Tue, Feb 28, 2023 at 11:53?PM G.W. Haywood via perl5-porters <
perl5-porters@perl.org> wrote:

> >> ... because of my pathological aversion
> >> to github (and github's aversion to my browser), I simply won't do it.
> >
> > Why not? Why can't you do:
> >
> > git clone https://github.com/Perl/perl5.git
>
> Can you remember ADSL?
>
> I *can* do it, but I won't.


So this is an aversion to git, then, not github.

I'm not going to waste time arguing about how productivity is so much
higher with (some) modern tools. This project has been on git for many
years and that's not going to change for the foreseeable future.

On Mon, Feb 27, 2023, at 05:17, demerphq wrote:
> There seems to be this idea that if we deprecate something that we have two release cycles, IOW, two *years*, before we have to get stuff fixed, and that the only code which might be broken by the deprecation is code that use fatal warnings, which we generally advise people not to use.

I saw later that you said this was said on IRC, so I don't want to say that this idea doesn't exist. I believe you heard this, which means somebody said it, which means somebody probably thinks it!

But on the "why is there a two year deprecation period" angle, I thought I should restate some of the reasoning behind that from discussions around when we got more formal about it:

Two years means that users who reliably upgrade their perl from their package manager, and upgrade their OS distribution, are very likely to see the deprecation in new perl from their distribution before they see breakage. It's about giving people a notice period, rather than giving ourselves time to put off fixing CPAN.

As Yves says, CPAN is affected on day one on the new version.

--
rjbs

On Wed, Mar 1, 2023, at 09:11, Dave Mitchell wrote:
> I'm particularly troubled that we have added two major deprecations
> very late in this release cycle:
>
> 5.37.9: deprecate Foo'Bar
> 5.37.10: (not even released yet): change 'experimental' to 'deprecated':
> ~~, given, when, etc.
>
> There seems to have been a lot of CPAN test suite breakage from these.
> Even if the fixes turn out to be trivial, and even if p5p volunteer to do
> all the fixing, it doesn't leave a lot of time to get new releases out and
> settled in.

I would like to see some details on the amount of breakage from 5.37.9 — I'm sure it's out there, I just haven't yet laid my eyes on it.

Not shipping the ~~ deprecation in final-zero at this point seems like probably the right move, anyway.

> So I think that
> a) such deprecations in future should only come early in the blead release
> cycle;

I definitely agree with this.

All this said: I think it's bad practice for an author to have their library fail user (not automated / smoke) tests on new deprecation warnings. The code is going to run just fine. They're the one who needs alerting. There are a bunch of arguments to be made on both sides here, and in the end the problem will remain: stuff got broken and needs to not be so broken by the time of final-zero.

--
rjbs

On Sun, 5 Mar 2023 at 00:11, Ricardo Signes <perl.p5p@rjbs.manxome.org> wrote:
>
> All this said: I think it's bad practice for an author to have their library fail user (not automated / smoke) tests on new deprecation warnings. The code is going to run just fine.

If a module produces vast quantities of deprecation warnings then it
is a bit debatable if it "runs fine", i know what you are saying, and
in the sense that "it does not die" the statement is true, but if the
warnings swamp whatever other output the script produces, then it is
arguable the script is not fine. I wonder if perhaps deprecation
warnings should be automatically "warn once". While dealing with the
fallout of the most recent deprecations warnings I have had to set up
filters to make it feasible to address the warnings that are coming
from modules test-suites. For Scope::Upper it was producing so many
warnings it was difficult to even see which test files were producing
the errors.

> They're the one who needs alerting.

I am not so sure about this. The transitive nature of this problems
makes it hard to say who actually needs to be alerted. It is entirely
possible that the module broken by a deprecation warning doesn't use
the feature being warned about, and the module that does isn't broken
by the deprecation warnings because it doesn't test it is warning
clean.

I think a big part of the problem is that the concept of author
testing is "new" (as compared to something like Test::More), and not
necessarily well publicized. For instance Test::More doesn't mention
it once. I know about it via the "Lancaster Consensus"[1], but I
wonder how much of the wider Perl development community is aware of it
and the concepts it introduces/introduced? Serious question, where do
we document this stuff? Is it even mentioned in the docs that come
with perl? I searched for the phrase "author testing" and it isn't
mentioned anywhere in core. Maybe we should do a better jobs
explaining the subtleties here?

cheers,
Yves
[1] https://github.com/Perl-Toolchain-Gang/toolchain-site/blob/master/lancaster-consensus.md
--
perl -Mre=debug -e "/just|another|perl|hacker/"

On 2023-03-05 18:23, demerphq wrote:

> [...] I wonder if perhaps deprecation
> warnings should be automatically "warn once".

Then some things should only warn once per total test,
others once per test-phase, others once per
$$, __PACKAGE__ / __FILE__, __LINE__.

(just saying that likely needs some interesting instrumentation)

-- Ruud


For the in-process-level, I often use this:

sub warn_once {
    my ( undef, $c_fname, $c_line )= caller;

    my $key= join "\0",
        $$,
        $c_fname,
        $c_line,
        @_;  #TODO: unify timestamps?; md5()

    state %warn_once;
    $warn_once{ $key }++
        or warn @_,
            ( (@_ and $_[-1] =~ /\n\z/) ? () : " at $c_fname line
$c_line. (warn_once)\n" );
}

On Wed, Mar 01, 2023 at 02:11:42PM +0000, Dave Mitchell wrote:
> On Mon, Feb 27, 2023 at 11:17:02AM +0100, demerphq wrote:
> > But that isn't correct. Odds are *very* likely we get CPAN breakage from
> > the very moment we deprecate something
>
> +1
>
> I'm particularly troubled that we have added two major deprecations
> very late in this release cycle:
>
> 5.37.9: deprecate Foo'Bar
> 5.37.10: (not even released yet): change 'experimental' to 'deprecated':
> ~~, given, when, etc.
>
> There seems to have been a lot of CPAN test suite breakage from these.
> Even if the fixes turn out to be trivial, and even if p5p volunteer to do
> all the fixing, it doesn't leave a lot of time to get new releases out and
> settled in.
>
> So I think that
> a) such deprecations in future should only come early in the blead release
> cycle;
> b) we should seriously consider backing out for now the two specific
> Foo'Bar and ~~ deprecations and re-adding them for 5.38.1.

Well, a month has passed, and in the last week or so we've had 9 new BBCs
related to the new smartmatch/when deprecation.

Are we agreed or not that the Foo'Bar and smartmatch deprecations
should be rolled back now, and re-applied in 5.39.1?

And if so, is anyone volunteering?

--
Never work with children, animals, or actors.

On Thu, 30 Mar 2023 at 18:32, Dave Mitchell <davem@iabyn.com> wrote:

> On Wed, Mar 01, 2023 at 02:11:42PM +0000, Dave Mitchell wrote:
> > On Mon, Feb 27, 2023 at 11:17:02AM +0100, demerphq wrote:
> > > But that isn't correct. Odds are *very* likely we get CPAN breakage
> from
> > > the very moment we deprecate something
> >
> > +1
> >
> > I'm particularly troubled that we have added two major deprecations
> > very late in this release cycle:
> >
> > 5.37.9: deprecate Foo'Bar
> > 5.37.10: (not even released yet): change 'experimental' to 'deprecated':
> > ~~, given, when, etc.
> >
> > There seems to have been a lot of CPAN test suite breakage from these.
> > Even if the fixes turn out to be trivial, and even if p5p volunteer to do
> > all the fixing, it doesn't leave a lot of time to get new releases out
> and
> > settled in.
> >
> > So I think that
> > a) such deprecations in future should only come early in the blead
> release
> > cycle;
> > b) we should seriously consider backing out for now the two specific
> > Foo'Bar and ~~ deprecations and re-adding them for 5.38.1.
>
> Well, a month has passed, and in the last week or so we've had 9 new BBCs
> related to the new smartmatch/when deprecation.
>
>

> Are we agreed or not that the Foo'Bar and smartmatch deprecations
> should be rolled back now, and re-applied in 5.39.1?
>

I am generally supportive of this for given/smartmatch. For apostrophe as a
package separator I am less convinced, seems like we have had less
turbulence associated with it, although the fact that we /still/ have
warnings related to it in core does not bode well for it generally. :-(

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?

And if so, is anyone volunteering?


To revert the deprecations? Seems simple enough I guess I dont mind
picking it up.

cheers,
Yves
[1] Meaning the author is non-responsive to bug reports and patches.
[2] https://github.com/Perl/perl5/issues/20782#issuecomment-1441953269

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

On Thu, Mar 30, 2023 at 09:12:42PM +0200, demerphq wrote:
> To revert the deprecations? Seems simple enough I guess I dont mind
> picking it up.

I looked at removing the deprecation warning for ' in symbols, while
leaving it documented as deprecated (since we're planning on actually
deprecating it, right?), but new tests prevent that.

Another option would be to completely undeprecate ' in symbols, and
make it a default on feature like indirect or multidimensional, and
disable it for 5.40, since I don't think some of the problem CPAN
distributions will ever be updated by their authors.

Tony

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.

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.

On Thu, Mar 30, 2023 at 3:20?PM demerphq <demerphq@gmail.com> 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 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.

-Dan

On Fri, 31 Mar 2023 at 03:24, Dan Book <grinnz@gmail.com> wrote:

> On Thu, Mar 30, 2023 at 3:20?PM demerphq <demerphq@gmail.com> 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. 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
now.

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.

Yves

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

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/"

On Fri, 31 Mar 2023 at 01:24, Tony Cook <tony@develop-help.com> wrote:

> On Thu, Mar 30, 2023 at 09:12:42PM +0200, demerphq wrote:
> > To revert the deprecations? Seems simple enough I guess I dont mind
> > picking it up.
>
> I looked at removing the deprecation warning for ' in symbols, while
> leaving it documented as deprecated (since we're planning on actually
> deprecating it, right?), but new tests prevent that.
>

We can adjust those warnings, right? I suspect i might have been involved
in creating those tests, but regardless, what man can make he can unmake,
at least in software. :-)


> Another option would be to completely undeprecate ' in symbols, and
> make it a default on feature like indirect or multidimensional, and
> disable it for 5.40, since I don't think some of the problem CPAN
> distributions will ever be updated by their authors.
>

Ah, that does make some sense, would it also work ok with smartmatch you
think?

cheers,
Yves

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

On Fri, Mar 31, 2023 at 11:28:29AM +0200, demerphq wrote:
> On Fri, 31 Mar 2023 at 01:24, Tony Cook <tony@develop-help.com> wrote:
> > Another option would be to completely undeprecate ' in symbols, and
> > make it a default on feature like indirect or multidimensional, and
> > disable it for 5.40, since I don't think some of the problem CPAN
> > distributions will ever be updated by their authors.
> >
>
> Ah, that does make some sense, would it also work ok with smartmatch you
> think?

I think smartmatch is is different.

Removing foo'bar is is kind of a style decision. There's really no good
reason why an old script written in perl 4 style shouldn't continue to
run, and breaking it just for the sake of breaking it seems wrong.
So putting a version guard on foo'bar removal seems like a good idea to
me.

On the other hand, we think smartmatch is broken, and we want to
discourage its use so that we can eventually introduce a 'fixed'
smartmatch/given etc which is not backwards compatible. To avoid code
silently breaking when we change smartmatch's behaviour, having a
deprecated/removed gap between the old and new behaviour sounds like a
good idea.

But another approach would be that we could support *two* smartmatch
behaviours in core simultaneously: if you have 'use v5.40' or 'use
feature "smartmatch2"' say, then you get the new behaviour. This would
avoid breaking the apparently large amount of code out there which already
uses this retrospectively experimental feature. So it's better for users,
at the price that perl core has to support both options.

I know I was the one who originally pushed for smartmatch to have a
deprecation warning, but I'm not so sure now.

But all of this strengthens my belief that perl 5.38.0 should not emit
deprecation warnings for smartmatch and foo'bar, until we have a more firm
consensus on the way forward.

--
No man treats a motor car as foolishly as he treats another human being.
When the car will not go, he does not attribute its annoying behaviour to
sin, he does not say, You are a wicked motorcar, and I shall not give you
any more petrol until you go. He attempts to find out what is wrong and
set it right.
-- Bertrand Russell,
Has Religion Made Useful Contributions to Civilization?

On 3/31/23 04:55, demerphq wrote:
> On Fri, 31 Mar 2023 at 03:24, Dan Book <grinnz@gmail.com> wrote:
>
> On Thu, Mar 30, 2023 at 3:20?PM demerphq <demerphq@gmail.com> 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:

https://www.debian.org/doc/manuals/developers-reference/pkgs.html#nmu

Perhaps some of that is applicable here?

Diab

On Thu, 30 Mar 2023 21:12:42 +0200, demerphq <demerphq@gmail.com> 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
>
> [2] https://github.com/Perl/perl5/issues/20782#issuecomment-1441953269

After reading your commentary in that thread, this claim of yours stands out:

> a commitment to keep cleaning it up for ever more

That is not the case. If you go through the process you gain ownership of the keys to the car, and you can absolutely just get into it, drive it to a different parking spot, get out, hang a sign on it "keys available for free" and be on your way.

In practical terms, it is perfectly appropriate to go through the normal process, bug the fix, then immediately enact this process: https://metacpan.org/about/faq#howtomarkadistributionthatisupforadoption

--
With regards,
Christian Walde

On Fri, 31 Mar 2023 17:49:05 +0200, Diab Jerius <dj.p5p@avoiding.work> wrote:

>
> In the Debian world these are called NMUs, Non-Maintainer-Uploads, and as with all things Debian, there’s a policy >around them:
>
> https://www.debian.org/doc/manuals/developers-reference/pkgs.html#nmu
>
> Perhaps some of that is applicable here?
>
> Diab
We already have that, albeit in bits and pieces.

One can request a transfer if author is unresponsive. https://pause.perl.org/pause/query?ACTION=pause_operating_model#4_2_requesting_an_indexing_permission_transfer

One can transfer to adoptme or request adoption. Either with zero involvement. https://pause.perl.org/pause/query?ACTION=pause_operating_model#4_5_1_adoptme
Or with a last call before transfer. https://pause.perl.org/pause/query?ACTION=pause_operating_model#4_5_2_handoff


--
With regards,
Christian Walde