Front page | perl.perl5.porters |
Postings from February 2018
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.Thread Previous | Thread Next