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

Reply via email to