Open Stack

James E. Blair wrote:
> Thierry Carrez <thierry at openstack.org> writes:
>> James E. Blair wrote:
>>>  * Any repo associated with an official OpenStack program is entitled to
>>>    use the openstack org.
>>>  * Programs may request an org for their program, with justification,
>>>    but in general we should limit the number of orgs in use.
>>
>> That's one way of doing it, although I find it a bit confusing.
>>
>> If you follow markmc's vision of having some repo deliveries tagged as
>> being part of the OpenStack "product", you could argue that the
>> openstack/ org should be restricted to "openstack product" repos. That
>> would be a convenient way of finding them.
>>
>> Alternatively you could limit the openstack/ org to "projects" and
>> require that all "programs" set up their own org (like
>> openstack-infra/). That way the orgs would mirror our taxonomy.
>>
>> I don't have strong feelings either way, and I think we can decide on
>> that once the first "programs" are set up.
> 
> Honestly, my first thought was "hey, we can have the orgs mirror the
> taxonomy, and that will be easy". 

Yes, that was my first thought as well. We have a number of conflicting
objectives here:

1. Make it easy to find "OpenStack projects" (jeblair)
2. Reduce org management overhead and project renames (jeblair)
3. Be able to link programs with their associated repositories (ttx)
4. Be potentially able to define a set of projects that are "the
OpenStack product" (markmc)

> But then I thought that having lots
> of orgs mostly just makes it harder for people to find projects, and we
> should treat the openstack org as less of a name prefix (such as
> "Openstack Nova") and more of a collection of OpenStack related
> repositories.  Since any program will, almost by definition, be working
> on code related to OpenStack, it makes sense to put it in there.
> 
> So this way we will end up with a smaller and simpler set of orgs (which
> is less infrastructure overhead for us to manage), and it means that
> people looking for a repo don't have to understand our project taxonomy
> to know where to find it.  Finally, this may mean fewer renames if our
> taxonomy changes in the future.

That's (1) and (2). Maybe we can address (3) and (4) in a way that
doesn't involve the github orgs ?

For (3) I think we could leverage a new field in projects.yaml that
would let us associate a project with a program, letting us
programatically find "all official projects" for ATC voting purposes, or
answer the question "which program does this repo belong to". After all,
those are not really end user questions, but rather taxonomists questions.

For (4) I guess we could use a field too, but this is a bit inconvenient
for end user discovery. Reducing the "openstack" org to projects that
are cloud-infrastructure-related (and excluding the projects that help
us achieve that goal) would make it clearer for end users to find our
"key deliverables" and ignore the rest...

To summarize, I think we can address my immediate taxonomy concerns
without having to match github orgs and programs, but there may still be
room for organizing orgs based on a "who consumes this" approach. But
that can be solved over the long run.

-- 
Thierry Carrez (ttx)