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. _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev