I think we should be pushing to get us added to comaint as much as possible.

If the author is unwilling to do so, we should insist that there needs 
to be some other comaint, so that the bus factor > 1.

> I think we should be pushing to get us added to comaint as much as =
possible.

Agreed =E2=80=94 I think p5p should, if possible, have co-maint on all =
core modules.

> If the author is unwilling to do so, we should insist that there needs =
to be some other comaint, so that the bus factor > 1.

I don=E2=80=99t think P5P can insist, for modules that are already in =
core. People can be encouraged, with an explanation for why, and I =
suspect that most people would agree.

It would be good to have a clearly documented model for modules being =
promoted into core, and that could include a requirement that in future =
P5P should get co-maint. That way if one of FROBOZZ=E2=80=99s modules is =
proposed for core, she can make an informed decision. And if she =
doesn=E2=80=99t want to give co-maint, the P5P can decide whether to =
fork the module into a new namespace, so that the functionality can be =
shipped with Perl, as just one possible solution.

Neil

On 04/06/2018 03:11 PM, Neil Bowers wrote:
>> I think we should be pushing to get us added to comaint as much as possible.
> Agreed — I think p5p should, if possible, have co-maint on all core modules.

I would say P5P *needs* to have comaint on it. The problem here is that
P5P is implicitly in charge of all the working state of all bundled
versions of dual-life modules by virtue of releasing it with perl. We
cannot release broken software or software that bundles broken software.

We have the freedom to patch it in core, so no need for comaint yet,
except if we patch something in blead and it is critical and the
upstream CPAN author is unavailable, we risk divergence, split brain,
and inconsistencies for users. Every module that is dual-life should
have more hands on deck for releases on both ends: perl core and CPAN.

Slaven just noted that Storable hasn't had a release in a while. Tony
fixed a bunch of stuff and merged patches from Reini that are important,
but they're not available on CPAN. This is bad. Luckily, P5P can release
and we don't have to chase down the previous releaser. Same for
PathTools which recently received a release by me - which is good,
because Steffen is pretty darn busy at the moment.

>
>> If the author is unwilling to do so, we should insist that there needs to be some other comaint, so that the bus factor > 1.
> I don’t think P5P can insist, for modules that are already in core. People can be encouraged, with an explanation for why, and I suspect that most people would agree.
>
> It would be good to have a clearly documented model for modules being promoted into core, and that could include a requirement that in future P5P should get co-maint. That way if one of FROBOZZ’s modules is proposed for core, she can make an informed decision. And if she doesn’t want to give co-maint, the P5P can decide whether to fork the module into a new namespace, so that the functionality can be shipped with Perl, as just one possible solution.


At the last core hackathon this was brought up and we resolved to
officially (though we haven't added it to any paper yet, but we should)
that we will not accept any additional modules into core unless:

1. There is more than one main maintainer. Someone to help with the
person in charge is too busy.
2. There is co-maint for P5P to do releases when they are required and
people are unavailable.

We have also expressed that P5P prefers to avoid making changes to
dual-life unless we cannot avoid it. This can happen when the authors
are unreachable or when the patch is required for blead. This is also in
cases where the author stepped down, as just happened with several
dual-life modules.

We also discussed approaching all dual-life module authors to request
adding P5P. So far I only got to corner Paul Evans who just replied with
"Yeah, that makes sense!" :)

In cases where the author refuses, we will have to review our options.
(It does also note a lack of cooperation with core, which is a problem
if your module is dual-life and we are responsible for its working state
within a perl release that we make...)

On Fri, Apr 6, 2018 at 2:11 PM, Neil Bowers <neil.bowers@cogendo.com> wrote=
:
>> If the author is unwilling to do so, we should insist that there needs t=
o be some other comaint, so that the bus factor > 1.
>
> I don=E2=80=99t think P5P can insist, for modules that are already in cor=
e. People can be encouraged, with an explanation for why, and I suspect tha=
t most people would agree.

This is one of those situations where the "admin" permission category
in PAUSE would have been helpful. Some modules originated in core, and
as such can be considered P5P's property (e.g. PathTools). In many
other cases we took modules in; in some of those cases the original
author has long since moved on though. We barely even know which is
which right now.

> It would be good to have a clearly documented model for modules being pro=
moted into core, and that could include a requirement that in future P5P sh=
ould get co-maint. That way if one of FROBOZZ=E2=80=99s modules is proposed=
 for core, she can make an informed decision. And if she doesn=E2=80=99t wa=
nt to give co-maint, the P5P can decide whether to fork the module into a n=
ew namespace, so that the functionality can be shipped with Perl, as just o=
ne possible solution.

We currently have such a clearly documented model actually, it's
called perlpolicy (section "contributed modules"). It's probably in
need of an update though.

Leon