[openstack-dev] RFC: Basic definition of OpenStack Programs and first batch

John Dickinson me at not.mn
Mon Jul 1 15:41:12 UTC 2013


On Jul 1, 2013, at 8: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.
> 
> 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.

I think the concern I have with the current discussions is that the definition is becoming so specific that we'll someday have such an over categorization of things to the point of "repos created on a Tuesday".

What is the end result here, and what are we trying to promote? I think we want to give ATC status to people who contribute to code that is managed as part of the OpenStack organization. In that sense, everything (ie nova, swift, neutron, cinder, etc) is a program, right? What happens if an existing "project" wants to deliver an independent code library? "Just put it in oslo!" may be the current answer, but moving a bunch of unrelated deliverables into oslo causes review issues (a separate review community) and may slow development. (that's actually not the argument I want to have in this email thread)

I'd suggest that everything we have today are "openstack programs". Many have multiple deliverables (eg a server side and a client side). As a specific example (only because it's what I'm most familiar with, not that this is something Swift is considering), if Swift wanted to separately deliver the swob library (replacement for WebOb) or our logging stuff, then they simply become another deliverable under the "Swift program".

I completely support (going back years now) the idea of having CI, QA, Docs, etc as additional "top-level" openstack things.

To reiterate, what are we trying to accomplish with further classification of code into programs and projects? What is lacking in the current structure that further classification (ie a new name) gets us?

--John


-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4082 bytes
Desc: not available
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20130701/dabdc183/attachment.bin>


More information about the OpenStack-dev mailing list