[tc][infra] When a project leaves OpenStack
This is a discussion I've been meaning to start for a very, very long while. The tl;dr of it is that when official OpenStack projects have ceased to meet our expectations for what it means to be OpenStack, allowing them to continue on in an unofficial capacity but otherwise unchanged has led to confusion among users. Finding a better way to handle project removals is my goal for this conversation. Inevitably, there are times when projects cannot continue to be a part of OpenStack. Often this is because development has ceased, and so we can retire their repositories cleanly leaving a notice to any remaining users that the project is unmaintained. Sometimes a project is unable or unwilling to continue to be a part of OpenStack officially, and we have made the choice to simply remove them from our governance but otherwise wish them well on their new journey. Unfortunately, more often than not, a formerly official project continuing development outside OpenStack is an indication it's nearing the end of its life, soon thereafter ceasing development and leaving behind an abandoned repository where even the most critical bugs go untriaged and proposed fixes unreviewed. This is the case for a lot of software which has ceased viability, so unsurprising, but given it was once a part of OpenStack there are users who simply assume it's still maintained and so it reflects negatively on us when they end up having a bad experience. One possibility we've entertained, over the years this topic has cropped up, is to declare that projects in the infrastructure we share (soon to be known as OpenDev) which were once an official part of OpenStack retain some residual TC jurisdiction so that if we notice their maintainers have disappeared we can take over and close down the project more thoroughly. This may work well enough in situations where it's brought to our attention, but will clearly not help the first people to notice this situation nor does it help in cases where we're never informed. With the "namespace explosion" coming in OpenDev, however, there's another option open to us. We could require that any development which continues after removal from OpenStack be done as a fork of the original. In theory we could have done that even with one common namespace, by requiring projects to either cease using this infrastructure entirely or change their name. Neither of these options is especially desirable. Now, however, we might consider allowing them to continue in the same infrastructure under the same repository name but in a different namespace. We would effectively close down development on the original repository following our normal retirement process, but could optionally also include a note mentioning where continued development is known to be taking place instead. Does anyone have other ideas to suggest? -- Jeremy Stanley
On Fri, Mar 15, 2019 at 10:57:54PM +0000, Jeremy Stanley wrote:
Now, however, we might consider allowing them to continue in the same infrastructure under the same repository name but in a different namespace.
Am I understanding you correctly in that you're saying git.opendev.org/openstack/project closes down; i.e. the master branch is replaced with a README to indicate the project is no longer maintained and ensure CI notices, but then something like git.opendev.org/neweffort/project could be started by interested parties; where as, normally (as an example) "neweffort/nova" wouldn't be a good name due to the obvious potential for confusion? If that is correct; branch/fork, tomato/tomato ... if master comes back to life it doesn't make any difference if you merge from a local branch or a remote one (fork). So it seems the advantage of a forked project is you can manage the cores/users/groups separately; but then if there's no cores/users/groups active on the original project, does it make a difference if people are given permissions to do this same work on a branch there? -i
On 2019-03-18 10:17:28 +1100 (+1100), Ian Wienand wrote:
On Fri, Mar 15, 2019 at 10:57:54PM +0000, Jeremy Stanley wrote: [...]
Now, however, we might consider allowing them to continue in the same infrastructure under the same repository name but in a different namespace.
Am I understanding you correctly in that you're saying
git.opendev.org/openstack/project
closes down; i.e. the master branch is replaced with a README to indicate the project is no longer maintained and ensure CI notices, but then something like
git.opendev.org/neweffort/project
could be started by interested parties; where as, normally (as an example) "neweffort/nova" wouldn't be a good name due to the obvious potential for confusion?
Yes, up until recently we've had a self-imposed limitation that no two projects in our Gerrit should have the same basename even if they're in different namespaces (though it seems we ended up with a couple[0][1] some time ago, perhaps as a result of a botched rename?). I'm suggesting that one option we might consider is to allow forks within our infrastructure for the same project basename, as an alternative to: 1. leaving the repository the way it is and only removing it from governance (status quo, seems to lead to downstream confusion due to assumptions of continued inclusion, especially when the effort around it later dissolves leaving the project abandoned) 2. declaring the OpenStack TC has jurisdiction to take over and properly retire any project which was once an official part of OpenStack, in the event that project ceases to be maintained (temporarily has the same issues as #1 and also means needing ways for users to point the situation out to us as well as tracking this retained control state) 3. requiring the maintainers to move the repository out of OpenDev's infrastructure so we can retire it properly where it used to be hosted (they may want to anyway, but we shouldn't assume ceasing to be an official part of OpenStack means they no longer want to share the same systems) 4. forcing the maintainers to rename their project completely so as to avoid it being confused with the prior effort which was considered an official part of OpenStack (developers can be very attached to the project names they choose, and the risk of being forced to choose a new name later if they decide to take it back out of OpenStack may dissuade them from considering inclusion in the first place)
If that is correct; branch/fork, tomato/tomato ... if master comes back to life it doesn't make any difference if you merge from a local branch or a remote one (fork). So it seems the advantage of a forked project is you can manage the cores/users/groups separately; but then if there's no cores/users/groups active on the original project, does it make a difference if people are given permissions to do this same work on a branch there?
I don't follow your comments here. The idea is that when any project ceases to be an official part of OpenStack (whether or not there are still developers who want to continue maintaining it outside of OpenStack TC jurisdiction) we could just follow the same consistent retirement process for its repositories. If folks want to continue with it once it is no longer part of OpenStack they still have options: create new repos in OpenDev with different names or using the same basenames in a different namespace and import all the previous code, or do their work outside of OpenDev from that point on (the OpenStack TC doesn't really have effective control to prevent any of those choices anyway). [0] https://review.openstack.org/#/admin/projects/stackforge/tripleo-ansible [0] https://review.openstack.org/#/admin/projects/openstack/tripleo-ansible -- Jeremy Stanley
On 15/03/19 6:57 PM, Jeremy Stanley wrote:
With the "namespace explosion" coming in OpenDev, however, there's another option open to us. We could require that any development which continues after removal from OpenStack be done as a fork of the original. In theory we could have done that even with one common namespace, by requiring projects to either cease using this infrastructure entirely or change their name. Neither of these options is especially desirable. Now, however, we might consider allowing them to continue in the same infrastructure under the same repository name but in a different namespace. We would effectively close down development on the original repository following our normal retirement process, but could optionally also include a note mentioning where continued development is known to be taking place instead.
I believe this is the correct approach. We should be keeping our trademark as far away as possible from projects we have no control over. - ZB
participants (3)
-
Ian Wienand
-
Jeremy Stanley
-
Zane Bitter