[tc][infra] When a project leaves OpenStack

Jeremy Stanley fungi at yuggoth.org
Mon Mar 18 15:30:20 UTC 2019


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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 963 bytes
Desc: not available
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20190318/23830747/attachment.sig>


More information about the openstack-discuss mailing list