Vishvananda Ishaya wrote: > The three questions are: > > 1. Which projects are “part of openstack”? > 2. Which projects are released as a single unit? > 3. Which projects are tested together
That's a good summary, yes. Currently we have a number of horizontal teams, which must support equally an always-increasing number of "integrated" projects. That means 1=2=3. But in the case of (3) it just might not make sense, and in the case of (2) it doesn't scale infinitely. That said, singling out the test infrastructure (3) and the release management (2) is a bit unfair to other horizontal efforts, like Documentation, Translations, or general QA, which also suffer from a scale issue. The Docs team, in particular, couldn't really scale either and already implemented two tiers within the integrated release -- the part they directly support, and the part they help / provide tools for. > The current answers are: > 1. Three levels incubation, integration, core > 2. Things that reach the integration level > 3. Things that reach the integration level. > > Some proposed answers: > 1. Lightweight incubation a la apache > 2. Monty’s layer1 > 3. Direct dependencies and close collaborators > > Discussing the propased answers(in reverse order): > I think we have rough consensus around 3: that we should move > towards functional testing for direct dependencies and let the > projects decide when they want to co-gate. The functional > co-gating should ideally be based on important use-cases. > > 2 is a bit murkier. In the interest of staying true to our roots > the best we can probably do is to allow projects to opt-out of > the coordinated release and for thierry to specifically select > which projects he is willing to coordinate. Any other project > could co-release with the integrated release but wouldn’t be > centrally managed by thierry. There is also a decision about > what the TCs role is in these projects. Like I said above, that seems to single out release management, while other horizontal efforts are facing the same challenge. I fear if we let each horizontal program choose which set of projects it supports, it will result in a bit of a mess, where no expectation is clearly set (project A is on the common release but Anne doesn't touch its docs directly, project B releases when it wants to and has Anne's team working on it directly...) If the "horizontal teams" all agree to directly support the same non-expanding set (for the sake of the exercise, let's call it layer #1), why not have it ? It's definitely a set that test infra, QA, Release Management and Docs would feel comfortable supporting, AFAIK. All the "other" projects would be able to get help and tools from those horizontal teams, but would just not be directly taken care of. This is how Docs currently work (the two tiers within integrated release), this is how Release management currently works (integrated vs. incubated), this is how the test infra would like to be able to work... Making sure we at least support the layer #1 is just a matter of setting the same basic expectations for the same basic set of projects. -- Thierry Carrez (ttx) _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev