Open Stack

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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/defcore-committee/attachments/20140912/e8d88b34/attachment.html>