Front page | perl.perl5.porters |
Postings from February 2018
Re: MJD modules are orhapns; please adopt them
Thread Previous
|
Thread Next
From:
demerphq
Date:
February 28, 2018 15:47
Subject:
Re: MJD modules are orhapns; please adopt them
Message ID:
CANgJU+V=i5h4aEJ5ft+RzC_uT-NgJbF9PjuLU6e3AkhbsaPnoA@mail.gmail.com
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/"
Thread Previous
|
Thread Next