[openstack-dev] [Neutron] A big tent home for Neutron backend code

Russell Bryant rbryant at redhat.com
Mon Apr 27 20:58:28 UTC 2015


On 04/22/2015 02:19 PM, Russell Bryant wrote:
> a) Adopt these as repositories under the Neutron project team.
> 
> In this case, I would see them operating with their own review teams as
> they do today to avoid imposing additional load on the neutron-core or
> neutron-specs-core teams.  However, by being a part of the Neutron team,
> the backend team would submit to oversight by the Neutron PTL.
> 
> There are some other details to work out to ensure expectations are
> clearly set for everyone involved.  If this is the path that makes
> sense, we can work through those as a next step.

Based on the feedback on this thread so far, this seems like the best
choice.  I said I'd come back with some more proposed details, so here
we are.  Let me know what seems off or missing here.


1) Process

The process for proposing the move of a repo into openstack/ and under
the Neutron project is to propose a patch to the openstack/governance
repository.  For example, if I were proposing moving networking-ovn, I
would add the following entry under Neutron in reference/projects.yaml:

    - repo: openstack/networking-ovn
      tags:
        - name: release:independent

For more information about the release:independent tag (and other
currently defined tags) see:

    http://governance.openstack.org/reference/tags/

The Neutron PTL must approve the change.  The TC clarified that once a
project has been approved (Neutron in this case), the project can add
additional repos without needing TC approval as long as the added
repositories are within the existing approved scope of the project.


http://git.openstack.org/cgit/openstack/governance/commit/?id=321a020cbcaada01976478ea9f677ebb4df7bd6d


2) Responsibilities

All affected repositories already have their own review teams.  The
sub-team working on the sub-project is entirely responsible for
day-to-day development.  That includes reviews, bug tracking, and
working on testing.

By being included, the project accepts oversight by the TC as a part of
being in OpenStack, and also accepts oversight by the Neutron PTL.


3) Criteria

As mentioned before, the Neutron PTL must approve the inclusion of each
additional repository under the Neutron project.  I suggest that the
primary criteria used should be the same as what the TC uses for new
OpenStack projects, at least where it makes sense:

http://governance.openstack.org/reference/new-projects-requirements.html

One detail that I expect might be controversial is around maturity.  I
think it's important that we recognize and embrace that from the very
beginning of many projects, they are indeed "one of us", even if it's
early in the development process.  We should *not* be using that as
entry criteria into what's considered OpenStack.

Instead, we should be looking to define project metadata to help people
understand what things are, including their features, limitations, and
maturity level.  The tags system being used by the TC is intended to
address this at an OpenStack-wide level.  Some additional work could be
done specific to Neutron, just with a page that lists backends and
information about them.

Any project that fails to meet the criteria later can be dropped at any
time.  For example, if some repo is clearly unmaintained, it can be removed.

-- 
Russell Bryant



More information about the OpenStack-dev mailing list