Open Stack

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
> too.
>

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
projects etc.).

>
> 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
>   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.
>
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20130701/e1b95bd0/attachment.html>