[OpenStack-DefCore] DefCore Meeting on Designated Sections, Thursday 11am PT

Auld, Will will.auld at intel.com
Fri Aug 29 21:33:17 UTC 2014


I completely agree Thierry. While the discussion was somewhat painful it does make it clear that no matter how much we want to make a technical decision it is really not the technical one that needs to be made here. I found it very interesting that it would be considered more acceptable to have a, I forget how it was phrased, "Compute driven by OpenStack" and a "Driven by OpenStack" rather than having one "Driven by OpenStack" that encompassed both even though the result is pretty much the same.  

I also like having separate meetings (not back to back) for getting input where possible. I don't think back to back will work because we will never be able to cut off discussion on one to move to the next and having different people interested in each will make choosing a reasonable time less possible. 

Thanks,

Will 

> -----Original Message-----
> From: Thierry Carrez [mailto:thierry at openstack.org]
> Sent: Friday, August 29, 2014 12:06 AM
> To: Rob_Hirschfeld at Dell.com; Defcore-committee at lists.openstack.org
> Subject: Re: [OpenStack-DefCore] DefCore Meeting on Designated
> Sections, Thursday 11am PT
> 
> Rob_Hirschfeld at Dell.com wrote:
> >    * Review DefCore Process Chart (attached) - time limited.
> >
> >    * Review Designated Sections Strawman
> > from https://etherpad.openstack.org/p/DefCoreLighthouse.5
> 
> The call yesterday was a bit busy, but I think we actually clarified
> something with respect to the "technical community input on designated
> sections" stage.
> 
> There are two types of proposals in the Designated Sections strawman.
> Some projects have /some/ designated sections, while some others don't
> have *any* designated section. In the latter case, at the heart of that
> decision is the fact that a lot of companies in the OpenStack ecosystem
> ship products that do not include the project at all, and Defcore would
> still like to allow those companies to use the "Powered by OpenStack"
> trademark license program. I totally respect those decisions: it's a
> hard call to make and it's the board prerogative and duty to make it.
> 
> But as far as technical feedback is concerned, it's difficult to ask
> Swift contributors if they agree that none of the code they wrote is
> necessary to call your product "powered by OpenStack". Of course they
> won't agree: it's actually not a judgment of technical value, it's just
> a trademark policy choice. By extension, it's difficult to ask the
> Technical Committee, the body representing all those contributors, to
> agree that part of the code they produce is not necessary or less
> important. That body can only give one answer, and will continue to do
> so.
> 
> Now, that doesn't mean you can't get any technical input on the
> Designated sections strawman, but quite the opposite: it just has to be
> organized differently. There is still a lot of value in technical input
> to precisely define designated sections lines in the case a project has
> /some/ designated sections. For example for Glance, does it make
> technically sense to consider the WSGI framework as replaceable or not.
> 
> So here would be my suggested way forward: for all the projects that
> have "some" designated sections (Nova, Glance, Cinder), organize a
> specific call/meeting calling all interested members of our technical
> community (individual TC members, project PTL, any contributor
> interested) to join and give feedback on the proposed split between
> designated and non-designated code in their project. That could be a
> 30-min-per-project thing in a 90-min time span, or 3 separate meetings.
> 
> FWIW, personally, I think the proposed split on Nova, Glance and Cinder
> makes technical sense.
> 
> --
> Thierry Carrez (ttx)
> 
> _______________________________________________
> Defcore-committee mailing list
> Defcore-committee at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/defcore-committee



More information about the Defcore-committee mailing list