Open Stack

All,

There is another aspect to Designated Sections that I feel is important and I hope not being missed.  At least It's an aspect that I'm looking for from designated code sections.   Perhaps it simply didn't surface in the call last week because it is easier to identify through other projects than those discussed on the call.

Back in the 'spider' discussions, one of the tensions identified was the need to not inhibit developers ability to innovate, while through the use of the OpenStack mark conveying code maturity, completeness and long term stability.  People developing applications, deploying and administrating OpenStack are keen to understand what and which features they can confidently write to and deploy, aka features that are mature, complete and will be sustainable for many future releases. Icehouse had close to 400 new features, Juno will have a similar amount. In fact I don't see that slowing down in any near future.  That shows great innovation! Yet even though we have declared that the integrated projects are ready for release, we know that not all of the features fit the "mature, complete and long term supportable" category.  Several of the blueprints even explicitly make that declaration.  

We don't want to block those. In fact the exact opposite, we want more. The beauty of enabling and including innovative features is for people to try them out and provide feedback and experience to the community.

But let's not miss the opportunity to also tell the ecosystem about those areas that are mature and dependable. We have a ton of features that fit that category. We need to identify those. The creation of capabilities helps but is not complete. This is best resolved through the creation of designated sections.   And that is why the TC is critical for the DefCore effort.  As Thierry delineates, asking the TC and PTLs opinion on  what code is business necessary is not the right question.

In my opinion, asking the PTLs and TC which code features / segments are mature, complete, sustainable and part of the long term vision is the right question to ask.

Regards,

AlanClark
  

>>> On 8/29/2014 at 01:06 AM, Thierry Carrez <thierry at openstack.org> wrote: 
> 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 desi
gnated 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.