<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Mon, Apr 27, 2015 at 3:58 PM, Russell Bryant <span dir="ltr"><<a href="mailto:rbryant@redhat.com" target="_blank">rbryant@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On 04/22/2015 02:19 PM, Russell Bryant wrote:<br>
> a) Adopt these as repositories under the Neutron project team.<br>
><br>
> In this case, I would see them operating with their own review teams as<br>
> they do today to avoid imposing additional load on the neutron-core or<br>
> neutron-specs-core teams. However, by being a part of the Neutron team,<br>
> the backend team would submit to oversight by the Neutron PTL.<br>
><br>
> There are some other details to work out to ensure expectations are<br>
> clearly set for everyone involved. If this is the path that makes<br>
> sense, we can work through those as a next step.<br>
<br>
</span>Based on the feedback on this thread so far, this seems like the best<br>
choice. I said I'd come back with some more proposed details, so here<br>
we are. Let me know what seems off or missing here.<br>
<br>
<br>
1) Process<br>
<br>
The process for proposing the move of a repo into openstack/ and under<br>
the Neutron project is to propose a patch to the openstack/governance<br>
repository. For example, if I were proposing moving networking-ovn, I<br>
would add the following entry under Neutron in reference/projects.yaml:<br>
<br>
- repo: openstack/networking-ovn<br>
tags:<br>
- name: release:independent<br>
<br>
For more information about the release:independent tag (and other<br>
currently defined tags) see:<br>
<br>
<a href="http://governance.openstack.org/reference/tags/" target="_blank">http://governance.openstack.org/reference/tags/</a><br>
<br>
The Neutron PTL must approve the change. The TC clarified that once a<br>
project has been approved (Neutron in this case), the project can add<br>
additional repos without needing TC approval as long as the added<br>
repositories are within the existing approved scope of the project.<br>
<br>
<br>
<a href="http://git.openstack.org/cgit/openstack/governance/commit/?id=321a020cbcaada01976478ea9f677ebb4df7bd6d" target="_blank">http://git.openstack.org/cgit/openstack/governance/commit/?id=321a020cbcaada01976478ea9f677ebb4df7bd6d</a><br>
<br>
<br>
2) Responsibilities<br>
<br>
All affected repositories already have their own review teams. The<br>
sub-team working on the sub-project is entirely responsible for<br>
day-to-day development. That includes reviews, bug tracking, and<br>
working on testing.<br>
<br>
By being included, the project accepts oversight by the TC as a part of<br>
being in OpenStack, and also accepts oversight by the Neutron PTL.<br>
<br>
<br>
3) Criteria<br>
<br>
As mentioned before, the Neutron PTL must approve the inclusion of each<br>
additional repository under the Neutron project. I suggest that the<br>
primary criteria used should be the same as what the TC uses for new<br>
OpenStack projects, at least where it makes sense:<br>
<br>
<a href="http://governance.openstack.org/reference/new-projects-requirements.html" target="_blank">http://governance.openstack.org/reference/new-projects-requirements.html</a><br>
<br>
One detail that I expect might be controversial is around maturity. I<br>
think it's important that we recognize and embrace that from the very<br>
beginning of many projects, they are indeed "one of us", even if it's<br>
early in the development process. We should *not* be using that as<br>
entry criteria into what's considered OpenStack.<br>
<br>
Instead, we should be looking to define project metadata to help people<br>
understand what things are, including their features, limitations, and<br>
maturity level. The tags system being used by the TC is intended to<br>
address this at an OpenStack-wide level. Some additional work could be<br>
done specific to Neutron, just with a page that lists backends and<br>
information about them.<br>
<br>
Any project that fails to meet the criteria later can be dropped at any<br>
time. For example, if some repo is clearly unmaintained, it can be removed.<br>
<div class="HOEnZb"><div class="h5"><br></div></div></blockquote><div><br></div><div>I'm +1 for all of this. Thanks for driving this Russell!<br></div><div> <br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5">
--<br>
Russell Bryant<br>
<br>
__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</div></div></blockquote></div><br></div></div>