develooper Front page | perl.perl5.porters | Postings from February 2018

Re: MJD modules are orhapns; please adopt them

Thread Previous | Thread Next
February 28, 2018 15:47
Re: MJD modules are orhapns; please adopt them
Message ID:
On 28 February 2018 at 16:21, Sawyer X <> wrote:
> On 02/28/2018 05:07 PM, demerphq wrote:
>> On 28 February 2018 at 15:54, Sawyer X <> wrote:
>>> On 02/26/2018 05:16 PM, demerphq wrote:
>>>> On 26 February 2018 at 12:05, Sawyer X <> 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. :-)


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