[openstack-dev] RFC: Basic definition of OpenStack Programs and first batch
john.griffith at solidfire.com
Mon Jul 1 15:25:00 UTC 2013
On Mon, Jul 1, 2013 at 9:03 AM, Mark McLoughlin <markmc at redhat.com> wrote:
> 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
I have to agree with Mark, although we talked about a lot of this in the
meeting, reading back through some of it seems off a bit. It seems that
all of the items listed are very much tied to a release (QA tests that
support new features for said release, Infra changes to support added
> 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?
Seems like a reasonable idea, although I sort of liked an idea more along
the lines of:
"Code or libraries associated with the development and operation of
OpenStack that's not an identifiable entity needed to stand up a production
environment". This almost works but OSLO may confuse it, however my view
is that OSLO libs for example are pulled in by the projects that use it so
I think this definition still technically works.
> '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
> 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.
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the OpenStack-dev