Open Stack

On Tue, 2013-06-25 at 18:58 +0200, Thierry Carrez wrote:
> Mark McLoughlin wrote:
> > [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.
> 
> I think I have a slightly different view.
> 
> We as a project produce a number of deliverables. Some of those (the
> "integrated projects") are released as a common, coordinated release at
> the end of our 6-month development cycles. The others (which include the
> python client libraries and the Oslo libraries) are released as-needed,
> although in some cases they borrow the same release cycle.

Oslo follows the the same release cycle as the server projects, because
they're part of the same "product" - the deliverables of Oslo don't have
any (intended) use other than as part of the integrated release. They're
not "borrowing" the same release cycle out of convenience, they're
fundamentally part of the same development cycle.

To take another example - say we split the Nova virt drivers out into
separate projects with a well defined interface between them and Nova
proper. They still should be part of the release. In this case, they'd
still be in the Nova program, but it's the same idea - Oslo libraries
are primarily just parts of the server projects split out and shared.

> I don't think we should start overloading the meaning of "integrated".
> So the way I see it you would have teams, potentially producing
> deliverables. If one of those deliverables is to be part of the
> "integrated release" then you want to become a "Project" and you need to
> go through Incubation so that we check that you won't fuck up the rest
> of the integrated projects. If your team works on other deliverables
> (Documentation, Oslo libraries) or helps other teams (Infrastructure,
> Release) then you can apply to become a "Program".

I'm not trying to overload terms here - "integrated", "project",
"program", etc. I need to parse and re-read your definitions of those
because there's some subtleties in your think that surprise me ... and
I'm not sure why all of these distinctions are so important.

Your subtlety seems to be that only the server products are in the
release and stuff like the OpenStack-producted libraries you need and
the documentation to support it are some separate deliverable from the
release?

Is the distinction you're making that the only things in the release
should be things which have gone through incubation?

To my mind, the single most important thing we do is produce a software
"product" (or "release", or "distribution") for people building clouds.
I can't see how documentation, client libraries and supporting libraries
aren't a fundamental part of that thing.

> All the deliverables from Projects + Programs are OpenStack deliverables
> and contributing to them grants you ATC status, and in return Projects
> and Programs are under the oversight of the TC.

I honestly don't really care much about ATC status in all of this. I'd
be happy for that to be really broad - any sort of a contribution to
anything officially part of the project.

> Do you think we need to distinguish between those deliverables, and tag
> some of them as being part of the OpenStack "product", and some others
> as merely production helpers ? I'm not sure that would add a lot of value...

There are things we expect people to download from OpenStack and use to
build a cloud. Producing that set of things is our main focus.

There are things (i.e. clients) that we expect people to download from
OpenStack and use to interact with OpenStack clouds. This is actually a
subset of the above, because you can't build a cloud without these
things.

There are things which are critically important to helping us produce
all of the above, but we don't expect cloud builders or cloud users to
ever need them.

Again, the first set of things and the target users (i.e. cloud
builders) are the main reason we're here. I think we should be really
clear about what's included in that set of things.

My first question for any new program - and something I'd expect to see
in their mission statement - is what things (if anything) the program
will be contributing to the set of things that will be compelling for
cloud builders.

Cheers,
Mark.