Open Stack

Hey,

On Mon, 2013-06-24 at 11:50 +0200, Thierry Carrez wrote:

> The TC would bless the *mission statement* of the program rather than
> the specific set of projects implemented to reach that goal.

This is a really nice way of putting it and you've captured a bunch of
other stuff very well too.

The main thing I think about is the integrated release[1] - i.e. the
categories I care about are "officially part of the release" and
"official and important OpenStack projects which aren't part of the
release".

Maybe this is just about a program's mission statement - as part of the
mission statement, you explain what the program will contribute to the
release. In the case of Oslo, it produces libraries to be included in
the release. In the case of Infrastructure, it doesn't produce anything
to be included in the release.

In the case of TripleO, does it produce anything to be included in the
release? I think it should, but it's not the entirety of its mission
statement either. That, for me, is the really interesting thing to
discuss about TripleO - what does it intend to produce for inclusion in
the integrated release?

In terms of incubation, you could say "new projects that are intended
for inclusion in the integrated release will go through incubation" ...
but that doesn't make sense in all cases. For example, there's not much
value in new oslo libraries going through an incubation cycle because
nothing would be able to use the library until it had exited incubation.

Cheers,
Mark.

[1] - ok, some caveats on what I mean by "integrated release" ...

We're producing software for people who want to build clouds. A software
"product", for want of a better term.

Right now, we say the official "service projects" (definition: a project
which exposes a REST API?) are "integrated projects" and that's what's
contained in our release. I think we also say that Oslo libraries are
part of the integrated release.

The way I see it, our release is a product and should contain any
official OpenStack software which provides a more complete experience
for people deploying OpenStack clouds.

The only change that would mean right now is that the client libraries
and docs would be part of the integrated release. Even if there are some
wonky details - like we have good reason to *also* release clients
independently of the release cycle for a different set of target users
(i.e. cloud users, not cloud builders) and that complete docs aren't a
blocker for the integrated release going out - I think the release is
weirdly incomplete without those considered a part of it.

Also, before any jumps in with "we shouldn't have releases, trunk should
always be releasable" ... that's mostly orthogonal. We'd still have a
concept of an integrated product - which includes more than just the
server products - which is always releaseable.