[openstack-dev] [ironic] When should a project be under Ironic's governance?

Jim Rollenhagen jim at jimrollenhagen.com
Wed Nov 2 14:37:21 UTC 2016


On Mon, Oct 17, 2016 at 4:27 PM, Michael Turek
<mjturek at linux.vnet.ibm.com> wrote:
> Hello ironic!
>
> At today's IRC meeting, the questions "what should and should not be a
> project be under Ironic's governance" and "what does it mean to be under
> Ironic's governance" were raised. Log here:
>
> http://eavesdrop.openstack.org/meetings/ironic/2016/ironic.2016-10-17-17.00.log.html#l-176
>
> See http://governance.openstack.org/reference/projects/ironic.html for a
> list of projects currently under Ironic's governance.
>
> Is it as simple as "any project that aides in openstack baremetal deployment
> should be under Ironic's governance"? This is probably too general (nova
> arguably fits here) but it might be a good starting point.
>
> Another angle to look at might be that a project belongs under the Ironic
> governance when both Ironic (the main services) and the candidate subproject
> would benefit from being under the same governance. A hypothetical example
> of this is when Ironic and the candidate project need to release together.
>
> Just some initial thoughts to get the ball rolling. What does everyone else
> think?

We discussed this during our contributor's meetup at the summit, and came to
consensus in the room, that in order for a repository to be under
ironic's governance:

* it must roughly fall within the TC's rules for a new project:
  http://governance.openstack.org/reference/new-projects-requirements.html
* it must not be intended for use with only a single vendor's hardware
(e.g. a library
  to handle iLO is not okay, a library to handle IPMI is okay).
* it must align with ironic's mission statement: "To produce an
OpenStack service
  and associated libraries capable of managing and provisioning
physical machines,
  and to do this in a security-aware and fault-tolerant manner."
* lack of contributor diversity is a chicken-egg problem, and as such
a repository
  where only a single company is contributing is okay.

I've proposed this as a docs patch: https://review.openstack.org/392685

We decided we should get consensus from all cores on that patch - meaning 80%
or more agree, and any that disagree will still agree to live by the
decision. So, cores,
please chime in on gerrit. :)

Once that patch lands, I'll submit a patch to openstack/governance to
shuffle projects
around where they do or don't fit.

// jim



More information about the OpenStack-dev mailing list