Open Stack

Completely agree with the need for (paraphrasing) "...disconnecting...
the question of which projects can grow under the OpenStack
development umbrella (which is TC territory)."

I would like the TC to define the umbrella and what we as a project
offer technically. An attempt at that is below. Sorry for my list
etiquette awkwardness but I just went from daily digest back to
"every" so I can't really embed comments the way I'd like.

On Thu, Nov 15, 2012 at 12:23 PM, Zane Bitter <zbitter at redhat.com> wrote:
> On 15/11/12 13:56, Thierry Carrez wrote:
>>
>> Zane Bitter wrote:
>>>
>>> In trademark terms, then, "Core" is all the remaining projects in
>>> OpenStack that haven't been put into an excluded category
>>> (Library/Gating/Supporting).
>>
>>
>> Well, I think the main idea behind Mark's motion is to separate the two
>> concepts. Bylaws define "Core" as "software modules which are part of an
>> integrated release and for which an OpenStack trademark may be used".
>> What Mark proposes is to make the trademark-protected "Core" the
>> *subset* of software modules (part of the integrated release) for which
>> an OpenStack trademark may be used.
>
>
> Sure, which is effectively creating another category... Library, Gating,
> Supporting, Core and Other. I'm not saying that would be _bad_, but I don't
> think it's _necessary_. My impression of the TC discussions is that folks
> are worried about whether we should add any more projects to OpenStack at
> all, not so much about whether new projects could use the OpenStack name
> when shipped independently. (If I've misinterpreted that and somebody *is*
> worried about the trademark, perhaps they could chime in?)
>
>>> [...]
>>> What I'm suggesting here is that trademarks are not so much "an issue
>>> that can be punted to the Board" as just a non-issue. I don't think
>>> there's any need to create another category that's excluded from the
>>> trademark because there is already broad agreement on what is excluded
>>> from the trademark (Library, Gating and Supporting projects) and why.
>>
>>
>> I disagree. There is clearly no consensus yet on what has the right to
>> use the "OpenStack" name, or what components you need to run in order to
>> call yourself "an OpenStack cloud". For example, Horizon is core, but
>> Rackspace and HP Clouds (while calling themselves OpenStack clouds)
>> don't use it. Disconnecting this question (which is BoD territory) from
>> the question of which projects can grow under the OpenStack development
>> umbrella (which is TC territory) is therefore useful.
>
>
> There *was* a suggestion in the thread that all (Core) OpenStack services
> should be required for an "OpenStack Cloud". However, if the BoD wanted to
> institute something like that (and I imagine it would be part of some kind
> of certification program) they would either have to use a trademark other
> than just "OpenStack" to do so or change the bylaws (which would be almost
> impossible). Because the current bylaws define Core as exactly the opposite:
> it's the set of things which are entitled to use the trademark even when
> shipped independently of the others.
>
> Existing usage by Rackspace, HP, SwiftStack and others is consistent with
> the bylaws. I'm not saying that implies a consensus; but nor is it evidence
> of a lack of consensus.
>
> I do think there is a broad consensus on what should _not_ be able to use
> the trademark. Everybody agrees that importing openstack-common into a
> project should not enable that project to use the OpenStack name. Everybody
> agrees that building a project on the openstack-ci infrastructure should not
> enable that project to use the OpenStack name.
>
> The intention of the bylaws seems to be that anything that both is part of
> OpenStack and is not in any of the Library/Gating/Supporting categories
> (which seem pretty well understood and agreed-upon) should be entitled to
> use the OpenStack name. Separating the trademark and project membership
> issues is basically inviting the Board to create another category - a
> category that I haven't heard anybody actually ask for, and which does
> nothing to alleviate the concerns of those who worry that *any* new projects
> take resources away from existing Core projects.

I'd like to comment on all the "privileges" (and therefore resources)
given to existing Core projects:
- track time at the Summit
- release management - daily tracking, release definitions through
blueprint tagging, an overall release schedule, and time at the weekly
Project meeting
- testing gated via DevStack
- website descriptions at http://www.openstack.org/software/
- bug triaging efforts

These are all resources that haven't really been mentioned besides CI
and doc support. We agree that CI and doc teams are expecting
additions from core projects, yet we take for granted somewhat all the
privileges associated with core.

What we need to ensure the conservation of resources is a definition
of what you get when you're core. Like Zane says, we're not that
worried about trademark. I myself worry about resource expectations
and scope for the resources we give to core.

What if we had "Nuclear" projects that get these shared resources:
- track time at the Summit every six months
- release management time at the weekly Project meeting
- testing gated via DevStack and/or tempest
- CI guidance
- documentation guidance

How could that help us define Core? Core could get a subset of the
shared resources:

- collective/shared track time at the Summit every six months
- collective/shared release time at the weekly Project meeting
- QA requirements - to be defined
- CI requirements - to be defined
- Doc requirements - to be defined

This pattern seems to be what we already do with Summit tracks
specifically. We may need well-defined resource allocation around Core
and a really strict definition of Nuclear.

Thoughts?
Anne

> If the BoD wants to create another category of trademark exceptions, they
> are of course welcome to do so, but I don't think the TC needs to be
> actively pushing for one. That would seem like a form of trademark policy
> advocacy, even if it's motivated by wanting to avoid trademark policy, which
> everybody in this discussion has been pretty unanimous about :)
>
> cheers,
> Zane.
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev