Open Stack

I think your reasoning is sound, provided we don't make it harder to follow 
through on "phase 2" of your proposal in icehouse by conceding the removal 
of a requirement that is intended to be quickly re-added.

Inertia being a thing that can cause such unintended consequences.

Openstack is software, which we as a community create (though heroic 
efforts which I can't claim credit for myself! But admire, encourage, and 
support all that much more as a beneficiary of those efforts).

OpenStack is an OpenSource Cloud Computing platform that meets the needs of 
public and private clouds regardless of size, by being simple to implement 
and massively scalable.

Our mission to produce it.

 I always find out mission statement a handy reminder when trying to make 
such weighty decisions.
https://wiki.openstack.org/wiki/Main_Page

(Note I took the poetic license to change "will meet" to "meets" now that 
we are 4 years in and the largest banks in the world run it.  Whether we've 
yet achieved 'simple to implement' or 'massively scalable' is an exercise 
left to the reader.)














On September 12, 2014 2:38:44 PM Doug Hellmann <doug at doughellmann.com> wrote:

> The point I have been trying to make is that because our community creates 
> code and not standards, we should not simply trademark an API without 
> including the implementation. For Swift, that means leaving the 
> capabilities out entirely for Havana because we are, for better or worse, 
> leaving the code out entirely. The net effect would be to say that your 
> OpenStack cloud or distribution does not need to include object storage at 
> all, or you can include an object storage system other than Swift without 
> applying the OpenStack trademark to it. That seems to be what at least some 
> of the distributors and deployers want, and seems like a reasonable 
> compromise until we can decide on whether multiple trademark designations 
> solve the problem in a different way.
>
> If we take this route, we will need to look at the non-designated sections 
> of code for all of the projects to ensure they do not represent the entire 
> implementation of any of the capabilities (I think probably not, but I 
> haven’t audited the list myself).
>
> I hope we can re-evaluate Swift when we look at the Icehouse version of 
> DefCore, because I would prefer to see all of our integrated projects 
> included in core, but moving ahead without object storage is a better 
> solution than requiring an API and essentially allowing someone to use our 
> name on their code.
>
> Doug
>
> On Sep 11, 2014, at 5:44 PM, Joshua McKenty <joshua at pistoncloud.com> wrote:
>
> > I don't see that symmetry, but I'm still +1 for the discussion with the 
> board.
> >
> > Sent from my iPhone
> >
> > On Sep 11, 2014, at 2:23 PM, "Rochelle.RochelleGrober" 
> <rochelle.grober at huawei.com> wrote:
> >
> >> +1
> >>
> >> It makes so much sense once the symmetry was pointed out:
> >> If there are no required capabilities, then there is no designated code.
> >> If there is no designated code, then there are no required capabilities.
> >>
> >> --Rocky
> >>
> >> From: Auld, Will [mailto:will.auld at intel.com]
> >> Sent: Thursday, September 11, 2014 1:49 PM
> >> To: Rob_Hirschfeld at Dell.com; Defcore-committee at lists.openstack.org
> >> Subject: Re: [OpenStack-DefCore] Results from Community Meetings > 
> discussion/+1 about reconsidering Havana Swift as a core capability
> >>
> >> +1
> >>
> >> From: Rob_Hirschfeld at Dell.com [mailto:Rob_Hirschfeld at Dell.com]
> >> Sent: Thursday, September 11, 2014 1:35 PM
> >> To: Defcore-committee at lists.openstack.org
> >> Subject: [OpenStack-DefCore] Results from Community Meetings > 
> discussion/+1 about reconsidering Havana Swift as a core capability
> >>
> >> DefCore,
> >>
> >> We just completed our two community meetings.  Community attendance was 
> light but the dialogs where good.
> >>
> >> I am still working to get input from the PTLs against the designated 
> sections; however, I do not think that we are blocked at this point with 
> the following consideration: Swift capabilities should not be considered 
> core for Havana.
> >>
> >> I have gotten significant and consistent feedback that the two Swift 
> capabilities should not be included in Havana Core.  This has come from 
> multiple sources, a variety of interests, and different reasons were given.
> >>
> >> The final straw came today during community review of Swift when the 
> point was made (by Doug Hellman) that if there are no designated sections 
> that having required capabilities does not make sense.
> >>
> >> While people arrive at this conclusion in different ways, I am confident 
> in saying that community consensus is to reconsider Swift core capabilities.
> >>
> >> I’d like your opinion (and/or +1) on presenting this to the board on 
> Thursday _before_ discussing the details of designated sections and process 
> flow.  I believe this change will greatly simplify the discussion and allow 
> us to proceed with the DefCore process and results.
> >>
> >> Thanks,
> >>
> >> Rob
> >> ______________________________
> >> Rob Hirschfeld
> >> Dell, Sr. Distinguished Cloud Solution Architect
> >> cell +1 512 909-7219 blog robhirschfeld.com, twitter @zehicle
> >> Please note, I am based in the CENTRAL (-6) time zone
> >>
> >> _______________________________________________
> >> Defcore-committee mailing list
> >> Defcore-committee at lists.openstack.org
> >> http://lists.openstack.org/cgi-bin/mailman/listinfo/defcore-committee
> > _______________________________________________
> > Defcore-committee mailing list
> > Defcore-committee at lists.openstack.org
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/defcore-committee
>
>
>
>
> ----------
> _______________________________________________
> 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/20140912/fcd539ec/attachment-0001.html>