On Mon, Jul 1, 2013 at 9:03 AM, Mark McLoughlin <mar...@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@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >
_______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
