Open Stack

Hey Thierry

I actually didn't notice this go by last week, the other thread got all
the attention.

On Wed, 2013-06-26 at 14:51 +0200, Thierry Carrez wrote:
> Hi everyone,
> 
> Yesterday at the TC meeting we agreed that as a first step to
> establishing programs, we should have a basic definition of them and
> establish the first (undisputed) ones.
> 
> We can solve harder questions (like if "horizontal efforts" should be a
> program or a separate thing, or where each current official repo exactly
> falls) as a second step.
> 
> So here is my proposal for step 1:
> 
> """
> 'OpenStack Programs' are efforts which are essential to the completion
> of our mission, but which do not produce deliverables included in the
> common release of OpenStack 'integrated' projects every 6 months, like
> Projects do.

Hmm, this wasn't what I understood our direction to be.

And maybe this highlights a subtle difference in thinking - as I see it,
Oslo absolutely is producing release deliverables. For example, in what
way was oslo.config 1.1.0 *not* a part of the grizzly release?

The idea that documentation isn't a part of our releases seems a bit off
too.

This distinction feels like it's based on an extremely constrained
definition of what constitutes a release.

> Programs can create any code repository and produce any deliverable
> they deem necessary to achieve their goals.
> 
> Programs are placed under the oversight of the Technical Committee, and
> contributing to one of their code repositories grants you ATC status.
> 
> Current efforts or teams which want to be recognized as an 'OpenStack
> Program' should place a request to the Technical Committee, including a
> clear mission statement describing how they help the OpenStack general
> mission and how that effort is essential to the completion of our
> mission. Programs do not need to go through an Incubation period.
> 
> The initial Programs are 'Documentation', 'Infrastructure', 'QA' and
> 'Oslo'. Those programs should retroactively submit a mission statement
> and initial lead designation, if they don't have one already.
> """
> 
> This motion is expected to be discussed and voted at the next TC
> meeting, so please comment on this thread.

It's funny, I think we're all fine with the idea of Programs but can't
quite explain what distinguishes a program from a project, etc. and
we're reaching for things like "programs don't produce release
deliverables" or "projects don't have multiple code repositories". I'm
nervous of picking a distinguishing characteristic that will
artificially limit what Programs can do.

Say we go with the "no release deliverables" definition and, by
extension, Oslo wasn't a program ... then what happens if the QA team
wanted a start producing a release deliverable? Say, a test suite to
validate that your Havana deployment isn't screwed up? Would they have
to drop the "program" moniker?

How about we say the distinction is whether a project exposes a public
REST API?

  'OpenStack Programs' are efforts which are essential to the completion
  of our mission. However, while they may produce release deliverables 
  which are included in our coordinated release every 6 months, 
  programs do not include projects which implement REST APIs intended to
  be exposed to the users of OpenStack clouds. Such projects are known 
  as 'integrated' projects and join our releases through the incubation 
  process.

In terms of the issue of integrated projects also producing client
libraries, that ties in nicely with the REST API distinction - if a
project is producing a server which exposes an API, of course it should
also produce a client for that API.

Cheers,
Mark.