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.
_______________________________________________
OpenStack-dev mailing list
[email protected]
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
