On 21 September 2014 09:06, Barry Warsaw <barry@python.org> wrote:
In the context of PyPI, I tend to think that teams can be an answer to a lot of the problem. I'm looking for example at one of the lazr.* packages I co-maintain on PyPI. The package has a number of individual owner roles, but I know that there are probably only two of those people who still care enough about the package to maintain it upstream, or would ever likely upload new versions to PyPI. Handling roles in this way is pretty inconvenient because there might be dozens of packages that some combination of those group of people would be responsible for. If I could create a LAZR team and manage roles within that team, and then assign ownership of a package to that team, it would be easier to administer.
That doesn't solve the problem where individuals have a strong preference for personal ownership of PyPI entries, but given that upstreams often are a team effort, I think it would go a long way toward helping easy transition efforts for PyPI ownership.
Right, it also better reflects the way a lot of folks are organising their work on GitHub/BitBucket/GitLab/RhodeCode/etc these days - you have a team of folks with relatively broad permissions as part of an "organisation" (e.g. PyPA) and then multiple projects within those teams. In theory, anyone on the developer list for the organisation can commit directly to any of the repos, but in practice we don't. However, adding teams support would mean a *lot* more engineering work on the PyPI/Warehouse side, so it won't be practical until after the Warehouse development effort comes to fruition and takes over the pypi.python.org domain, allowing the legacy PyPI application to be retired. A major part of that effort is actually cleaning up the PyPI APIs to separate "useful and necessary public interface" from "legacy PyPI implementation detail", so that those legacy features can simply never be implemented in Warehouse at all - that's fairly slow going, since it means a fair bit of negotiation with the client tool developers, as folks figure out what is needed and what isn't.
It might even allow for better handling of transitions. For example, if a package owner is not reachable for some period of time, and someone steps up to take it over, you could create a team and put both people in it, then transfer the ownership to that team.
That's sort of what happens now - the requestor is *added* to the admin list, but the previous maintainer remains as co-owner. Regards, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia