Mailing List Archive

MJD modules are orhapns; please adopt them
I have some modules in core (Memoize, Tie::File) and others that are
not but that are more or less widely used (Text::Template, maybe some
others). I have not been maintaining these and I am not likely to in
the future.

I hereby abandon them; they are now orphaned, and free for adoption by
any interested person. If nobody steps up, perhaps some kind person
would at least update the manuals to say “this module is
unmaintained”.

Feel free to send technical questions to me at mjd@cpan.org. (Feel
free to send policy questions also, but the answer to those is likely
to be "Sure, do whatever you like", so I suggest you just go ahead
with whatever you had planned.) Please do not reply to me here, as I
do not read this list regularly.

Thanks in advance. Share and enjoy!
Re: MJD modules are orhapns; please adopt them [ In reply to ]
Attempting to take over Devel::Trace.
v0.13 is here: http://perlmonks.org/?node_id=1174021

Message to modules@perl.org sent, comments on v0.13 welcome.

cheers,
0--gg-

From the keyboard of Mark Jason Dominus [23.02.18,13:46]:

>
> I have some modules in core (Memoize, Tie::File) and others that are
> not but that are more or less widely used (Text::Template, maybe some
> others). I have not been maintaining these and I am not likely to in
> the future.
>
> I hereby abandon them; they are now orphaned, and free for adoption by
> any interested person. If nobody steps up, perhaps some kind person
> would at least update the manuals to say “this module is
> unmaintained”.
>
> Feel free to send technical questions to me at mjd@cpan.org. (Feel
> free to send policy questions also, but the answer to those is likely
> to be "Sure, do whatever you like", so I suggest you just go ahead
> with whatever you had planned.) Please do not reply to me here, as I
> do not read this list regularly.
>
> Thanks in advance. Share and enjoy!
>

--
_($_=" "x(1<<5)."?\n".q·/)Oo. G°\ /
/\_¯/(q /
---------------------------- \__(m.====·.(_("always off the crowd"))."·
");sub _{s./.($e="'Itrs `mnsgdq Gdbj O`qkdq")=~y/"-y/#-z/;$e.e && print}
Re: MJD modules are orhapns; please adopt them [ In reply to ]
FYI: You can transfer first-come or comaint permissions to ADOPTME via
https://pause.perl.org/pause/authenquery?ACTION=share_perms to indicate
that you are willing to allow any interested party to request permissions
on them without your involvement. Or you can give comaint permissions to
HANDOFF to indicate that you want to give up first-come permissions but not
without your involvement. Keep in mind transferring first-come is permanent
and not reversible.

More info:
https://github.com/Perl-Toolchain-Gang/toolchain-site/blob/master/lancaster-consensus.md#flagging-abandoned-modules-and-modules-requesting-help

-Dan

On Fri, Feb 23, 2018 at 8:46 AM, Mark Jason Dominus <mjd@plover.com> wrote:

>
> I have some modules in core (Memoize, Tie::File) and others that are
> not but that are more or less widely used (Text::Template, maybe some
> others). I have not been maintaining these and I am not likely to in
> the future.
>
> I hereby abandon them; they are now orphaned, and free for adoption by
> any interested person. If nobody steps up, perhaps some kind person
> would at least update the manuals to say “this module is
> unmaintained”.
>
> Feel free to send technical questions to me at mjd@cpan.org. (Feel
> free to send policy questions also, but the answer to those is likely
> to be "Sure, do whatever you like", so I suggest you just go ahead
> with whatever you had planned.) Please do not reply to me here, as I
> do not read this list regularly.
>
> Thanks in advance. Share and enjoy!
>
Re: MJD modules are orhapns; please adopt them [ In reply to ]
Please, please be careful who you transfer permissions to -- "any
interested person" leaves open the possibility that someone meaning well
could take over who is not sufficiently qualified to maintain modules of
such importance to the Perl ecosystem.

If you wish to give up first-come permissions entirely, I would suggest
giving first-come to one of the PAUSE admins or the pumpking, who can
suitably vet any successors.


On Fri, Feb 23, 2018 at 5:46 AM, Mark Jason Dominus <mjd@plover.com> wrote:

>
> I have some modules in core (Memoize, Tie::File) and others that are
> not but that are more or less widely used (Text::Template, maybe some
> others). I have not been maintaining these and I am not likely to in
> the future.
>
> I hereby abandon them; they are now orphaned, and free for adoption by
> any interested person. If nobody steps up, perhaps some kind person
> would at least update the manuals to say “this module is
> unmaintained”.
>
> Feel free to send technical questions to me at mjd@cpan.org. (Feel
> free to send policy questions also, but the answer to those is likely
> to be "Sure, do whatever you like", so I suggest you just go ahead
> with whatever you had planned.) Please do not reply to me here, as I
> do not read this list regularly.
>
> Thanks in advance. Share and enjoy!
>
Re: MJD modules are orhapns; please adopt them [ In reply to ]
On 02/23/2018 08:54 PM, Karen Etheridge wrote:
> Please, please be careful who you transfer permissions to -- "any
> interested person" leaves open the possibility that someone meaning
> well could take over who is not sufficiently qualified to maintain
> modules of such importance to the Perl ecosystem.

Agreed.

>
> If you wish to give up first-come permissions entirely, I would
> suggest giving first-come to one of the PAUSE admins or the pumpking,
> who can suitably vet any successors.

Furthermore, any module that is dual-core should have at least two
maintainers (or at least two co-maints). If you can also add "P5P" to
those, it would allow p5p to make releases when either one or both are
not available.
Re: MJD modules are orhapns; please adopt them [ In reply to ]
On 26 February 2018 at 12:05, Sawyer X <xsawyerx@gmail.com> wrote:
>
>
> On 02/23/2018 08:54 PM, Karen Etheridge wrote:
>> Please, please be careful who you transfer permissions to -- "any
>> interested person" leaves open the possibility that someone meaning
>> well could take over who is not sufficiently qualified to maintain
>> modules of such importance to the Perl ecosystem.
>
> Agreed.
>
>>
>> If you wish to give up first-come permissions entirely, I would
>> suggest giving first-come to one of the PAUSE admins or the pumpking,
>> who can suitably vet any successors.
>
> Furthermore, any module that is dual-core should have at least two
> maintainers (or at least two co-maints). If you can also add "P5P" to
> those, it would allow p5p to make releases when either one or both are
> not available.

Is there a reason we dont just make Perl upstream for Memoize and
Tie::File and move these modules from cpan/ to dist/?

Then neither of these concerns are material. The perl5porters would handle them.

Yves

--
perl -Mre=debug -e "/just|another|perl|hacker/"
Re: MJD modules are orhapns; please adopt them [ In reply to ]
On 02/26/2018 05:16 PM, demerphq wrote:
> On 26 February 2018 at 12:05, Sawyer X <xsawyerx@gmail.com> wrote:
>>
>> On 02/23/2018 08:54 PM, Karen Etheridge wrote:
>>> Please, please be careful who you transfer permissions to -- "any
>>> interested person" leaves open the possibility that someone meaning
>>> well could take over who is not sufficiently qualified to maintain
>>> modules of such importance to the Perl ecosystem.
>> Agreed.
>>
>>> If you wish to give up first-come permissions entirely, I would
>>> suggest giving first-come to one of the PAUSE admins or the pumpking,
>>> who can suitably vet any successors.
>> Furthermore, any module that is dual-core should have at least two
>> maintainers (or at least two co-maints). If you can also add "P5P" to
>> those, it would allow p5p to make releases when either one or both are
>> not available.
> Is there a reason we dont just make Perl upstream for Memoize and
> Tie::File and move these modules from cpan/ to dist/?
>
> Then neither of these concerns are material. The perl5porters would handle them.

The only reason not to do it is in case someone outside p5p would like
to maintain them.
Re: MJD modules are orhapns; please adopt them [ In reply to ]
On 28 February 2018 at 15:54, Sawyer X <xsawyerx@gmail.com> wrote:
>
>
> On 02/26/2018 05:16 PM, demerphq wrote:
>> On 26 February 2018 at 12:05, Sawyer X <xsawyerx@gmail.com> wrote:
>>>
>>> On 02/23/2018 08:54 PM, Karen Etheridge wrote:
>>>> Please, please be careful who you transfer permissions to -- "any
>>>> interested person" leaves open the possibility that someone meaning
>>>> well could take over who is not sufficiently qualified to maintain
>>>> modules of such importance to the Perl ecosystem.
>>> Agreed.
>>>
>>>> If you wish to give up first-come permissions entirely, I would
>>>> suggest giving first-come to one of the PAUSE admins or the pumpking,
>>>> who can suitably vet any successors.
>>> Furthermore, any module that is dual-core should have at least two
>>> maintainers (or at least two co-maints). If you can also add "P5P" to
>>> those, it would allow p5p to make releases when either one or both are
>>> not available.
>> Is there a reason we dont just make Perl upstream for Memoize and
>> Tie::File and move these modules from cpan/ to dist/?
>>
>> Then neither of these concerns are material. The perl5porters would handle them.
>
> The only reason not to do it is in case someone outside p5p would like
> to maintain them.

But then we have to decide if they are competent. And if they ask and
we decide they aren't then we are insulting someone who is trying to
help.

If the maint burden is low, then I think we should just take them into
core. If people want to adopt MJD's non core modules then fine, but if
we are going to impose restrictions on who can do the maintenance,
including vetting them, we should just take them onto ourself. That
way we guarantee enough maintainers and we dont risk insulting
someone.

cheers,
Yves

--
perl -Mre=debug -e "/just|another|perl|hacker/"
Re: MJD modules are orhapns; please adopt them [ In reply to ]
On 02/28/2018 05:07 PM, demerphq wrote:
> On 28 February 2018 at 15:54, Sawyer X <xsawyerx@gmail.com> wrote:
>>
>> On 02/26/2018 05:16 PM, demerphq wrote:
>>> On 26 February 2018 at 12:05, Sawyer X <xsawyerx@gmail.com> wrote:
>>>> On 02/23/2018 08:54 PM, Karen Etheridge wrote:
>>>>> Please, please be careful who you transfer permissions to -- "any
>>>>> interested person" leaves open the possibility that someone meaning
>>>>> well could take over who is not sufficiently qualified to maintain
>>>>> modules of such importance to the Perl ecosystem.
>>>> Agreed.
>>>>
>>>>> If you wish to give up first-come permissions entirely, I would
>>>>> suggest giving first-come to one of the PAUSE admins or the pumpking,
>>>>> who can suitably vet any successors.
>>>> Furthermore, any module that is dual-core should have at least two
>>>> maintainers (or at least two co-maints). If you can also add "P5P" to
>>>> those, it would allow p5p to make releases when either one or both are
>>>> not available.
>>> Is there a reason we dont just make Perl upstream for Memoize and
>>> Tie::File and move these modules from cpan/ to dist/?
>>>
>>> Then neither of these concerns are material. The perl5porters would handle them.
>> The only reason not to do it is in case someone outside p5p would like
>> to maintain them.
> But then we have to decide if they are competent. And if they ask and
> we decide they aren't then we are insulting someone who is trying to
> help.

This is a subtle point. MJD has to decide who it is, not us. He passes
the mantle, unless he moved it to ADOPTME and then it's - I believe -
PAUSE admins. I'm sure MJD will take into account our request to have
more than one (co-)maintainer and I'm certain he would like it to be
someone reliable.

On competency, It is easier to be direct and say "We believe we will do
a better job at this" now than later. It is honest and earnest.

But I don't think this replies directly to your comment of, "this could
be picked up by someone who will not do a good job," and my answer to
this is: You're right.


> If the maint burden is low, then I think we should just take them into
> core. If people want to adopt MJD's non core modules then fine, but if
> we are going to impose restrictions on who can do the maintenance,
> including vetting them, we should just take them onto ourself. That
> way we guarantee enough maintainers and we dont risk insulting
> someone.


I don't object to this course, as long as MJD is willing. I will just
note that finding people interested in helping us with these modules
could help reduce the effort on maintaining it in the future to beyond us.
Re: MJD modules are orhapns; please adopt them [ In reply to ]
On 28 February 2018 at 16:21, Sawyer X <xsawyerx@gmail.com> wrote:
>
>
> On 02/28/2018 05:07 PM, demerphq wrote:
>> On 28 February 2018 at 15:54, Sawyer X <xsawyerx@gmail.com> wrote:
>>>
>>> On 02/26/2018 05:16 PM, demerphq wrote:
>>>> On 26 February 2018 at 12:05, Sawyer X <xsawyerx@gmail.com> wrote:
>>>>> On 02/23/2018 08:54 PM, Karen Etheridge wrote:
>>>>>> Please, please be careful who you transfer permissions to -- "any
>>>>>> interested person" leaves open the possibility that someone meaning
>>>>>> well could take over who is not sufficiently qualified to maintain
>>>>>> modules of such importance to the Perl ecosystem.
>>>>> Agreed.
>>>>>
>>>>>> If you wish to give up first-come permissions entirely, I would
>>>>>> suggest giving first-come to one of the PAUSE admins or the pumpking,
>>>>>> who can suitably vet any successors.
>>>>> Furthermore, any module that is dual-core should have at least two
>>>>> maintainers (or at least two co-maints). If you can also add "P5P" to
>>>>> those, it would allow p5p to make releases when either one or both are
>>>>> not available.
>>>> Is there a reason we dont just make Perl upstream for Memoize and
>>>> Tie::File and move these modules from cpan/ to dist/?
>>>>
>>>> Then neither of these concerns are material. The perl5porters would handle them.
>>> The only reason not to do it is in case someone outside p5p would like
>>> to maintain them.
>> But then we have to decide if they are competent. And if they ask and
>> we decide they aren't then we are insulting someone who is trying to
>> help.
>
> This is a subtle point. MJD has to decide who it is, not us. He passes
> the mantle, unless he moved it to ADOPTME and then it's - I believe -
> PAUSE admins. I'm sure MJD will take into account our request to have
> more than one (co-)maintainer and I'm certain he would like it to be
> someone reliable.
>
> On competency, It is easier to be direct and say "We believe we will do
> a better job at this" now than later. It is honest and earnest.
>
> But I don't think this replies directly to your comment of, "this could
> be picked up by someone who will not do a good job," and my answer to
> this is: You're right.

FWIW, That wasn't my point. Someone else raised it. I just responded
because it puts us in a bad situation.

>
>
>> If the maint burden is low, then I think we should just take them into
>> core. If people want to adopt MJD's non core modules then fine, but if
>> we are going to impose restrictions on who can do the maintenance,
>> including vetting them, we should just take them onto ourself. That
>> way we guarantee enough maintainers and we dont risk insulting
>> someone.
>
>
> I don't object to this course, as long as MJD is willing. I will just
> note that finding people interested in helping us with these modules
> could help reduce the effort on maintaining it in the future to beyond us.

I think these modules are pretty stable and we can handle it.

Note I am *only* talking about MJD's modules in core. Anything else is
none of my business. :-)

Yves

--
perl -Mre=debug -e "/just|another|perl|hacker/"
Re: MJD modules are orhapns; please adopt them [ In reply to ]
In <01b5cfcc-6a82-9f2e-d121-bbe721d38ca8@gmail.com> (28 Feb) Sawyer X said:
> This is a subtle point. MJD has to decide who it is, not us.

No. You deal with it. Sorry this wasn't clear from my original message.

> I don't object to this course, as long as MJD is willing.

Sure, do whatever you like.

In <1660.1519393564@plover.com> (23 Feb) Mark Jason Dominus said:
> Feel free to send policy questions also, but the answer to those is
> likely to be "Sure, do whatever you like", so I suggest you just go
> ahead with whatever you had planned.
Re: MJD modules are orhapns; please adopt them [ In reply to ]
On Wed, Feb 28, 2018 at 4:07 PM, demerphq <demerphq@gmail.com> wrote:
> But then we have to decide if they are competent. And if they ask and
> we decide they aren't then we are insulting someone who is trying to
> help.
>
> If the maint burden is low, then I think we should just take them into
> core. If people want to adopt MJD's non core modules then fine, but if
> we are going to impose restrictions on who can do the maintenance,
> including vetting them, we should just take them onto ourself. That
> way we guarantee enough maintainers and we dont risk insulting
> someone.

I'd strongly prefer to have as little modules as possible
upstream=blead unless there's an inherent reason why it ought to be
kept close to core. That said, p5p having ownership over essential
core modules is generally useful (especially when maintainers are less
than responsive).

Leon
Re: MJD modules are orhapns; please adopt them [ In reply to ]
On Wed, Feb 28, 2018 at 12:40 PM, Leon Timmermans <fawaka@gmail.com> wrote:

> On Wed, Feb 28, 2018 at 4:07 PM, demerphq <demerphq@gmail.com> wrote:
> > But then we have to decide if they are competent. And if they ask and
> > we decide they aren't then we are insulting someone who is trying to
> > help.
> >
> > If the maint burden is low, then I think we should just take them into
> > core. If people want to adopt MJD's non core modules then fine, but if
> > we are going to impose restrictions on who can do the maintenance,
> > including vetting them, we should just take them onto ourself. That
> > way we guarantee enough maintainers and we dont risk insulting
> > someone.
>
> I'd strongly prefer to have as little modules as possible
> upstream=blead unless there's an inherent reason why it ought to be
> kept close to core. That said, p5p having ownership over essential
> core modules is generally useful (especially when maintainers are less
> than responsive).
>
> Leon
>

Another issue with making them blead-upstream is that reporting bugs to
rt.perl.org is categorically more difficult than with rt.cpan.org or github
due to the consistent spamfilter issues over the past couple years. I am
unable to report bugs from my dev machine (they are silently dropped for
unknown reasons) and there is no web interface to do so. It's also less
simple for users to look through all bugs related to that particular module.

-Dan
Re: MJD modules are orhapns; please adopt them [ In reply to ]
On 1 Mar 2018 04:55, "Dan Book" <grinnz@gmail.com> wrote:

On Wed, Feb 28, 2018 at 12:40 PM, Leon Timmermans <fawaka@gmail.com> wrote:

> On Wed, Feb 28, 2018 at 4:07 PM, demerphq <demerphq@gmail.com> wrote:
> > But then we have to decide if they are competent. And if they ask and
> > we decide they aren't then we are insulting someone who is trying to
> > help.
> >
> > If the maint burden is low, then I think we should just take them into
> > core. If people want to adopt MJD's non core modules then fine, but if
> > we are going to impose restrictions on who can do the maintenance,
> > including vetting them, we should just take them onto ourself. That
> > way we guarantee enough maintainers and we dont risk insulting
> > someone.
>
> I'd strongly prefer to have as little modules as possible
> upstream=blead unless there's an inherent reason why it ought to be
> kept close to core. That said, p5p having ownership over essential
> core modules is generally useful (especially when maintainers are less
> than responsive).
>
> Leon
>

Another issue with making them blead-upstream is that reporting bugs to
rt.perl.org is categorically more difficult than with rt.cpan.org or github
due to the consistent spamfilter issues over the past couple years. I am
unable to report bugs from my dev machine (they are silently dropped for
unknown reasons) and there is no web interface to do so. It's also less
simple for users to look through all bugs related to that particular module.

-Dan

Maybe we should just get that fixed.

Yves