[Distutils] Create formal process for claiming 'abandoned' packages

[Nick Coghlan]

On 21 September 2014 01:34, Donald Stufft <donald at stufft.io> wrote:
>
> Most of the Linux distros have some mechanism for someone to claim that a
> particular
> package in the distro is no longer maintained and to attempt to take it
> over, though
> that is somewhat different.

For reference, Fedora's non-responsive maintainer policy:
https://fedoraproject.org/wiki/Policy_for_nonresponsive_package_maintainers

"Just fork it" usually isn't an acceptable solution in the distro
case, as it creates an incredible amount of rework in other packages
for the distro maintainers *and* for distro users as they also need to
adjust to the new name. Even when *we're* the ones creating the new
tool (e.g. the currently ongoing yum -> dnf transition), it's entirely
possible that at the end of process, the new tool (or a compatibility
shim based on it) will take over the original name to minimise the
ripple effects on the rest of the ecosystem.

When forks of major upstream packages happen (ranging from relative
small ones like PIL -> Pillow to core dependency changes and community
splits like XFree86 -> x.org), the amount of rework generated just on
a per-distro basis can be significant, let alone after you account for
folks consuming upstream directly. (Triggering external rework is also
one of the largest costs associated with major platform upgrades, like
Python 2 -> 3, Gnome 2->3, KDE 3->4, the Windows 8-bit -> UTF-16-LE
transition, Windows security hardening, RHEL/CentOS major version
number bumps, etc. In those cases, the main mitigation effort is to
maintain the old platform for an extended period, to allow the cost to
be spread out over several years, rather than having to be addressed
in a small time window).

I do like the preferred contact mechanism listed in the Fedora policy
guide though: filing a bug against the package in the Fedora issue
tracker. Including the relevant project issue tracker in the required
points of contact for PyPI ownership transfer could be a good
enhancement over doing it via email, and providing a public record of
the interaction between the two communities by cross-linking the PyPI
bug requesting the transfer, and the project bug notifying them of the
project transfer request.

The usage of the project issue tracker also makes it clear that going
to the PyPI admins *won't help* if you're having a dispute with
currently active project maintainers.

Adapting Fedora's process wholesale might look something like:

1. Requestor starts with a ticket on the PyPI issue tracker
2. If there isn't already one on the project issue tracker, the
requestor is instructed to file it and link it from the PyPI issue
3. The PyPI admins will notify the registered package maintainer of
the transfer request (and both tickets) via all available contact
mechanisms
4. The requestor must ping the project ticket and the PyPI ticket
after 7 (or more) days, and then again after another 7 (or more) days
5. If there's no response 7 (or more) days after the second ping, the
requestor must notify distutils-sig in addition to pinging both
tickets a third time
6. If there's no response 7 (or more) days after notifying
distutils-sig, then the requestor is *added* to the maintainer list
for the project

Exception: I'm not sure how best to handle cases where the affected
project has no public bug tracker. However, the requestor should
definitely be required to *set up* a bug tracker for the project in
such cases as part of the handover of responsibility.

Some advantages of such an approach:

1. It's mostly public - the only "offline" part is the notification
from the PyPI admins directly to the existing PyPI package maintainers
2. It should be scalable, as the folks making the transfer request are
responsible for doing most of the work. If they don't do the work, the
transfer simply doesn't happen
3. The minimum transfer time is 4 weeks, which will cover many
instances of vacation (etc), and provide plenty of time for folks to
notice the request (including folks that aren't the package
maintainer, but may be aware if they're away from an extended period,
and haven't arranged for anyone else to handle bug reports in the
meantime)

I had a harder time finding the relevant Debian policy info, but this
seems to be it:
https://www.debian.org/doc/manuals/developers-reference/beyond-pkging.html#mia-qa

One common element to both systems: both Fedora and Debian have the
capacity for maintainers to officially declare a package an "orphan".
While I don't think it's urgent, I'd actually really like to see such
a feature for PyPI at some point in the future, independently of the
ownership transfer questions. A library like my own shell-command, for
example, is usable as is, but there's zero chance I'll ever go back to
working on it myself, as I no longer like the basic design concept. If
I could flag that directly in PyPI, that would be useful in a few
ways:

1. Folks that are *considering* using it would get a clear notice that
it's unmaintained and perhaps move on to something with an active
maintainer
2. Tools like "pip list" could grow a "--orphaned" option to show
unmaintained dependencies
3. A simpler "fast path" could be added to the ownership transfer
process for already orphaned packages

One possible way approach to handling cases where folks are out of
touch for extended periods without arranging for someone else to
handle responding to upstream maintenance requests is to offer a
calendar application where highly engaged package maintainers could
explicitly notify the PyPI admins of an extended lack of availability.

We probably don't need to go that far (folks that would be engaged
enough to do that are likely to also be engaged enough to have other
other folks participating on their issue tracker that would be aware
of their extended absence), but if we ever decided such a service
would be useful, Fedora also maintain a calendar app specifically to
allow folks to indicate lack of availability:
https://apps.fedoraproject.org/calendar/list/vacation/ (Project page
for the Flask app itself: http://fedocal.readthedocs.org)

We probably don't need to go that far, but it would be one possible
way for project maintainers to explicitly tell the PyPI admins about
lack of availability, without needing to change PyPI itself, and
without trying to manage such notifications manually via email.

Regards,
Nick.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia