[OpenStack-DefCore] Suggestions on trademark changes, possible meeting 10/2 or earlier

Rochelle.RochelleGrober rochelle.grober at huawei.com
Tue Sep 23 19:06:00 UTC 2014


Taking up the gauntlet.



What I heard from the board meeting was:



DefCore did and is doing what it is supposed to do:  Identify mature, critical widespread OpenStack functionality and corresponding code that represents the foundational pieces of the OpenStack contributions for a specific release; identify tests which would certify these foundational components.  No politics.  All technical.  What DefCore is really saying about these parts identified by DefCore is that they are community vetted, tested under fire, in the wild, and represent the solid and mature parts of OpenStack; these identified parts can be trusted.  Well, as well as they are tested.  We might want to change bug priorities in the projects such anything affecting identified core functionality/code gets marked critical and gets fixed first, but that's another issue.





Now, these foundational components are just that, components.  As the tent expands, we'll have a lot more components that meet the 12 aspects of foundational and yet will be able to operate exclusive of much or all of the rest of the OpenStack integrated releases.  So, we need to step forward with a plan that takes these realities into account.  But what DefCore is really saying is that these parts identified by DefCore are community vetted, tested under fire, in the wild and are important.



We appear to be most of the way to a solution with the full distro and the standalone components (but not the names):

*         OpenStack distro (OpenStack full stack??? Certified OpenStack?  Whole OpenStack?)

*         OpenStack component(powered by OpenStack XXX?)

But the hard part is the mostly got it all parts or when other stuff is added to what would be considered an OpenStack product or distro.



So, how about we define the third mark as: it is built on the DefCore identified code and contains no extensions or new code that displaces any of the DefCore identified set of functionality/code.  This would allow for:

*         Powered by OpenStack

*         Built on OpenStack

*         OpenStack Solid

*         Etc



But this means that you couldn't use this mark is say, you provide ObjectStore but it's not swift.  You provide block storage, but it doesn't use the parts of Cinder identified by DefCore process.  If you substitute foundational pieces, the only mark you can use is the component marks that you incorporate.  And those component marks should also be certified through testing as defined by the full tempest test suite for that component at that release.



Which means to get an "OpenStack XXX" mark, you need to pass Refstack tests as identified for the release you want the mark on.



Then all three sets of marks could be certified with testing to back them up and we have a real certification program.



--Rocky





-----Original Message-----
From: Rob_Hirschfeld at Dell.com [mailto:Rob_Hirschfeld at Dell.com]
Sent: Tuesday, September 23, 2014 9:39 AM
To: joshua at pistoncloud.com; simon at dreamhost.com
Cc: Defcore-committee at lists.openstack.org
Subject: Re: [OpenStack-DefCore] Suggestions on trademark changes, possible meeting 10/2 or earlier



> From: Joshua McKenty [mailto:joshua at pistoncloud.com]

> While I love the tenor of your approach, I think we need at least three more:



Thank you both!  Yes, we need more alternatives for discussion.  Anyone willing to expand the pool with some non-traditional choices?



_______________________________________________

Defcore-committee mailing list

Defcore-committee at lists.openstack.org

http://lists.openstack.org/cgi-bin/mailman/listinfo/defcore-committee
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/defcore-committee/attachments/20140923/dec7c87d/attachment-0001.html>


More information about the Defcore-committee mailing list