Open Stack

On 29/05/14 05:26, Thierry Carrez wrote:
> Sean Dague wrote:
>> I honestly just think we might want to also use it as a time to rethink
>> our program concept. Because all our programs that include projects that
>> are part of the integrated release are 1 big source tree, and maybe a
>> couple of little trees that orbit it (client and now specs repos). If we
>> always expect that to be the case, I'm not really sure why we built this
>> intermediate grouping.
>
> Programs were established to solve two problems. First one is the
> confusion around project types. We used to have project types[1] that
> were trying to reflect and include all code repositories that we wanted
> to make "official". That kept on changing, was very confusing, and did
> not allow flexibility for each team in how they preferred to organize
> their code repositories. The second problem that solved was to recognize
> non-integrated-project efforts which were still essential to the
> production of OpenStack, like Infra or Docs.
>
> [1] https://wiki.openstack.org/wiki/ProjectTypes
>
> "Programs" just let us bless goals and teams and let them organize code
> however they want, with contribution to any code repo under that
> umbrella being considered "official" and ATC-status-granting.

This is definitely how it *should* work.

I think the problem is that we still have elements of the 'project' 
terminology around from the bad old days of the pointless 
core/core-but-don't-call-it-core/library/gating/supporting project 
taxonomy, where project == repository. The result is that every time a 
new project gets incubated, the reaction is always "Oh man, you want a 
new *program* too? That sounds really *heavyweight*." If people treated 
the terms 'program' and 'project' as interchangeable and just referred 
to repositories by another name ('repositories', perhaps?) then this 
wouldn't keep coming up.

(IMHO the quickest way to effect this change in mindset would be to drop 
the term 'program' and call the programs projects. In what meaningful 
sense is e.g. Infra or Docs not a "project"?)

> I would be
> a bit reluctant to come back to the projecttypes mess and create
> categories of programs (integrated projects on one side, and "others").

I agree, but why do we need different categories? Is anybody at all 
confused about this? Are there people out there installing our custom 
version of Gerrit and wondering why it won't boot VMs?

The categories existed largely because of the aforementioned strange 
definition of 'project' and the need to tightly control the membership 
of the TC. Now that the latter is no longer an issue, we could eliminate 
the distinction between programs and projects without bringing the 
categories back.

> Back to the topic, the tension here is because DNS is seen as a
> "network" thing and therefore it sounds like it makes sense under
> "Networking". But "programs" are not categories or themes. They are
> teams aligned on a mission statement. If the teams are different
> (Neutron and Designate) then it doesn't make sense to artificially merge
> them just because you think of "networking" as a theme. If the teams
> converge, yes it makes sense. If they don't, we should just create a new
> program. They are cheap and should reflect how we work, not the other
> way around.

+1

cheers,
Zane.