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