On 21 September 2014 01:34, Donald Stufft <donald@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#m... 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@gmail.com | Brisbane, Australia