Open Stack

> > -----Original Message-----
> > From: Thierry Carrez [mailto:thierry at openstack.org

> > 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.


Thierry,

Thanks for your summary [snipped].  The DefCore is working as per the TC recommendation and I'm hopeful that you are correct about consensus technical guideance for Designated Sections since the Board's likely position is towards a smaller core.

I do want to stress that Core is not about picking "important" code.  I agree that all of the code is important.  The DefCore process is about picking long term stable and mature code that serves as the foundation for products and ecosystems.

I suspect the challenge here is that many in the community believe that while APIs should be long term and stable, implementations behind those API need flexibility to innovate.  This was a central theme around the original DefCore principles that the Board implemented in Hong Kong.  The Swift/Ceph challenge is not unique.  There are many places where is a substantial body of the commercial implementations (and user community too) that want the freedom to change parts of the implementation.  This is a widely held position that surfaces often in my numerous discussions about core.

I don't have a position on individual projects or specific vendor products (Dell no longer offer's a standalone OpenStack solution); however, I believe that this principle is imperative for the long term health and overall strength of OpenStack.

Rob
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/defcore-committee/attachments/20140903/110a5d10/attachment.html>