<p dir="ltr">On Jul 16, 2016 3:36 AM, "Nick Coghlan" <<a href="mailto:ncoghlan@gmail.com">ncoghlan@gmail.com</a>> wrote:<br>
><br>
> On 15 July 2016 at 23:59, Thomas Kluyver <<a href="mailto:thomas@kluyver.me.uk">thomas@kluyver.me.uk</a>> wrote:<br>
> > On Fri, Jul 15, 2016, at 01:25 AM, Donald Stufft wrote:<br>
> ><br>
> > Off the top of my head I can only really think of PIL, and *maybe* suds.<br>
> > Unless there’s a lot of these maybe all we really need is a policy for when<br>
> > administrators can/will edit the page to direct people towards a different<br>
> > project or a way to add an admin message directing people to another<br>
> > project.<br>
> ><br>
> ><br>
> > Proposal: let's put some such manual intervention policy in place for now.<br>
> > Apply it for PIL to point to Pillow, and query the active suds forks to see<br>
> > if there's a generally agreed successor.<br>
> ><br>
> > If this works well, great! If the admins are flooded with 'successor<br>
> > requests', then we can come back to question of an automated mechanism. If<br>
> > there are too many abandoned packages with competing successors, that's a<br>
> > trickier problem to solve, but at least we'd be considering it with more<br>
> > information.<br>
><br>
> +1, although I'd propose decoupling the policy aspect ("Project X has<br>
> been declared unmaintained, with Project Y as its official successor")<br>
> from the implementation aspect of how that policy is applied in PyPI<br>
> and pip. That way we wouldn't be adding to the existing workload of<br>
> the PyPI admins - their involvement would just be implementing the<br>
> collective policy decisions of the PyPA, rather than being directly<br>
> tasked with making those policy decisions themselves.<br>
><br>
> For example, suppose we had a "Replacement Packages" page on<br>
><a href="http://packaging.python.org"> packaging.python.org</a>, that documented cases like PIL -> Pillow, where:<br>
><br>
> - a de facto community standard package has become unmaintained<br>
> - attempts to reach the existing maintainers to transfer ownership have failed<br>
> - a de facto replacement package has emerged<br>
> - the overall newcomer experience for the Python ecosystem is being<br>
> harmed by legacy documentation that still recommends the old de facto<br>
> standard<br>
><br>
> Adding new entries to that page would then require filing an issue at<br>
><a href="https://github.com/pypa/python-packaging-user-guide/issues/"> https://github.com/pypa/python-packaging-user-guide/issues/</a> to<br>
> establish:<br>
><br>
> - the package being replaced is a de facto community standard<br>
> - the package being replaced is important to the user experience of<br>
> newcomers to the Python ecosystem<br>
> - the package being replaced has become unmaintained<br>
> - a newer community fork has gained sufficient traction to be deemed a<br>
> de facto successor<br>
> - the existing maintainer has been contacted, and is unresponsive to<br>
> requests to accept help with maintenance<br>
><br>
> If *all* of those points are credibly established, *then* the package<br>
> replacement would be added to the "Replacement Packages" list on<br>
><a href="http://packaging.python.org"> packaging.python.org</a>.<br>
><br>
> How that list was utilised in PyPI and pip, as well as in other<br>
> package introspection tools (e.g. IDEs, VersionEye), would then be the<br>
> decision of the designers of those tools.</p>
<p dir="ltr">So, there could be RDFa in the project detail pages and a JSONLD key/dict in the project metadata indicating this community-reviewed edge or edges.</p>
<p dir="ltr">As an unreified triple:<br>
(pypi:PIL pypa:recommendsPackageInstead pypi:pillow)</p>
<p dir="ltr">As a reified edge:<br>
_:1234 a pypa:SupersededByEdge;<br>
  schema:dateCreated iso8601;<br>
  schema:description "reason";<br>
  schema:url <<a href="https://github.com/pypa/python-packaging-user-guide/issues/">https://github.com/pypa/python-packaging-user-guide/issues</a>/1234>;<br>
  pypa:origPackage pypi:PIL;<br>
  pypa:otherPackage pypi:pillow;<br>
  .</p>
<p dir="ltr">These are N3/Turtle syntax; which is expressable as a JSONLD block in HTML and/or as RDFa HTML. (#PEP426JSONLD)</p>
<p dir="ltr">><br>
> > As further examples: pydot, pexpect and python-modernize have all been<br>
> > unmaintained, leading to forks springing up. In all three cases, some of the<br>
> > forkers eventually coordinated to contact the original maintainer, get<br>
> > upload rights, and make new releases with the original name. It would<br>
> > certainly have been nice if that could have happened sooner in each case,<br>
> > but I doubt that any technical fix would have made a big difference.<br>
><br>
> The PyCA folks obtaining maintenance access to PyOpenSSL would be<br>
> another example of this being navigated successfully without a long<br>
> term split.<br>
><br>
> One of the longest running eventually resolved examples to date would<br>
> be the multi-year setuptools/distribute split, and I'd actually<br>
> consider that the ideal outcome of this process in general: while we<br>
> understand entirely that folks may need to step away from open source<br>
> software maintenance for a wide range of reasons, we strongly prefer<br>
> to see projects providing critical functionality handed over to a new<br>
> set of maintainers that have earned the trust of either the original<br>
> maintainer or the wider community rather than letting them languish<br>
> indefinitely.<br>
><br>
> We can't mandate that any given project invest time in succession<br>
> planning though, so having a system in place to designate successor<br>
> projects at the ecosystem level when maintainers aren't able to<br>
> resolve it at a project level makes sense.<br>
><br>
> Cheers,<br>
> Nick.<br>
><br>
> --<br>
> Nick Coghlan   |   <a href="mailto:ncoghlan@gmail.com">ncoghlan@gmail.com</a>   |   Brisbane, Australia<br>
> _______________________________________________<br>
> Distutils-SIG maillist  - <a href="mailto:Distutils-SIG@python.org"> Distutils-SIG@python.org</a><br>
><a href="https://mail.python.org/mailman/listinfo/distutils-sig"> https://mail.python.org/mailman/listinfo/distutils-sig</a><br>
</p>