On Thu, Nov 10, 2016 at 11:21 AM, <arkady.kanev...@dell.com> wrote: > Second try > > -----Original Message----- > From: Kanevsky, Arkady > Sent: Thursday, November 10, 2016 10:08 AM > To: OpenStack Development Mailing List (not for usage questions) > <openstack-dev@lists.openstack.org> > Subject: RE: [openstack-dev] [ironic] When should a project be under Ironic's > governance? > > Fully agree. > How do we propose to handle dependency of Ironic version on specific version > of a driver? > Clearly distros can do it but we will not have a version for user of upstream > to use without building it themselves. > I am only referring to ironic drivers that do pass CI voting that user expect > availability of.
I'm not quite sure what you mean here. For optional libraries (like proliantutils), we use a driver-requirements.txt file that is versioned the same as ironic, which both packagers and users can use to determine what version of a library is required. Libraries may also carry stable branches like ironic, whether they are inside or outside of ironic governance. For in-tree drivers, well, those are versioned the same as ironic. For out-of-tree drivers, it's the same as optional libraries, except that we don't have a requirements.txt-style file. Folks maintaining out-of-tree drivers will need to document what version of their driver works with what version of ironic. Of course, these drivers can also carry stable branches. Does that help? // jim > Thanks, > Arkady > > -----Original Message----- > From: Jim Rollenhagen [mailto:j...@jimrollenhagen.com] > Sent: Wednesday, November 02, 2016 9:37 AM > To: OpenStack Development Mailing List (not for usage questions) > <openstack-dev@lists.openstack.org> > Subject: Re: [openstack-dev] [ironic] When should a project be under Ironic's > governance? > > On Mon, Oct 17, 2016 at 4:27 PM, Michael Turek <mjtu...@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 > > __________________________________________________________________________ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > __________________________________________________________________________ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev