<div dir="ltr"><div class="gmail_default" style="font-family:courier new,monospace"><br></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Mon, Jul 1, 2013 at 9:03 AM, Mark McLoughlin <span dir="ltr"><<a href="mailto:markmc@redhat.com" target="_blank">markmc@redhat.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hey Thierry<br>
<br>
I actually didn't notice this go by last week, the other thread got all<br>
the attention.<br>
<div class="im"><br>
On Wed, 2013-06-26 at 14:51 +0200, Thierry Carrez wrote:<br>
> Hi everyone,<br>
><br>
> Yesterday at the TC meeting we agreed that as a first step to<br>
> establishing programs, we should have a basic definition of them and<br>
> establish the first (undisputed) ones.<br>
><br>
> We can solve harder questions (like if "horizontal efforts" should be a<br>
> program or a separate thing, or where each current official repo exactly<br>
> falls) as a second step.<br>
><br>
> So here is my proposal for step 1:<br>
><br>
> """<br>
> 'OpenStack Programs' are efforts which are essential to the completion<br>
> of our mission, but which do not produce deliverables included in the<br>
> common release of OpenStack 'integrated' projects every 6 months, like<br>
> Projects do.<br>
<br>
</div>Hmm, this wasn't what I understood our direction to be.<br>
<br>
And maybe this highlights a subtle difference in thinking - as I see it,<br>
Oslo absolutely is producing release deliverables. For example, in what<br>
way was oslo.config 1.1.0 *not* a part of the grizzly release?<br>
<br>
The idea that documentation isn't a part of our releases seems a bit off<br>
too.<br></blockquote><div><br></div><div class="gmail_default" style="font-family:'courier new',monospace">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.).</div>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
This distinction feels like it's based on an extremely constrained<br>
definition of what constitutes a release.<br>
<div class="im"><br>
> Programs can create any code repository and produce any deliverable<br>
> they deem necessary to achieve their goals.<br>
><br>
> Programs are placed under the oversight of the Technical Committee, and<br>
> contributing to one of their code repositories grants you ATC status.<br>
><br>
> Current efforts or teams which want to be recognized as an 'OpenStack<br>
> Program' should place a request to the Technical Committee, including a<br>
> clear mission statement describing how they help the OpenStack general<br>
> mission and how that effort is essential to the completion of our<br>
> mission. Programs do not need to go through an Incubation period.<br>
><br>
> The initial Programs are 'Documentation', 'Infrastructure', 'QA' and<br>
> 'Oslo'. Those programs should retroactively submit a mission statement<br>
> and initial lead designation, if they don't have one already.<br>
> """<br>
><br>
> This motion is expected to be discussed and voted at the next TC<br>
> meeting, so please comment on this thread.<br>
<br>
</div>It's funny, I think we're all fine with the idea of Programs but can't<br>
quite explain what distinguishes a program from a project, etc. and<br>
we're reaching for things like "programs don't produce release<br>
deliverables" or "projects don't have multiple code repositories". I'm<br>
nervous of picking a distinguishing characteristic that will<br>
artificially limit what Programs can do.<br>
<br>
Say we go with the "no release deliverables" definition and, by<br>
extension, Oslo wasn't a program ... then what happens if the QA team<br>
wanted a start producing a release deliverable? Say, a test suite to<br>
validate that your Havana deployment isn't screwed up? Would they have<br>
to drop the "program" moniker?<br>
<br>
How about we say the distinction is whether a project exposes a public<br>
REST API?<br></blockquote><div><br></div><div class="gmail_default" style="font-family:'courier new',monospace">Seems like a reasonable idea, although I sort of liked an idea more along the lines of:</div><div class="gmail_default" style="font-family:'courier new',monospace">
"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.</div>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="im"><br>
'OpenStack Programs' are efforts which are essential to the completion<br>
</div> of our mission. However, while they may produce release deliverables<br>
which are included in our coordinated release every 6 months,<br>
programs do not include projects which implement REST APIs intended to<br>
be exposed to the users of OpenStack clouds. Such projects are known<br>
as 'integrated' projects and join our releases through the incubation<br>
process.<br>
<br>
In terms of the issue of integrated projects also producing client<br>
libraries, that ties in nicely with the REST API distinction - if a<br>
project is producing a server which exposes an API, of course it should<br>
also produce a client for that API.<br>
<br>
Cheers,<br>
Mark.<br>
<div class="HOEnZb"><div class="h5"><br>
<br>
_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</div></div></blockquote></div><br></div></div>