Hey, On Mon, 2013-06-24 at 11:50 +0200, Thierry Carrez wrote:
> The TC would bless the *mission statement* of the program rather than > the specific set of projects implemented to reach that goal. This is a really nice way of putting it and you've captured a bunch of other stuff very well too. The main thing I think about is the integrated release[1] - i.e. the categories I care about are "officially part of the release" and "official and important OpenStack projects which aren't part of the release". Maybe this is just about a program's mission statement - as part of the mission statement, you explain what the program will contribute to the release. In the case of Oslo, it produces libraries to be included in the release. In the case of Infrastructure, it doesn't produce anything to be included in the release. In the case of TripleO, does it produce anything to be included in the release? I think it should, but it's not the entirety of its mission statement either. That, for me, is the really interesting thing to discuss about TripleO - what does it intend to produce for inclusion in the integrated release? In terms of incubation, you could say "new projects that are intended for inclusion in the integrated release will go through incubation" ... but that doesn't make sense in all cases. For example, there's not much value in new oslo libraries going through an incubation cycle because nothing would be able to use the library until it had exited incubation. Cheers, Mark. [1] - ok, some caveats on what I mean by "integrated release" ... We're producing software for people who want to build clouds. A software "product", for want of a better term. Right now, we say the official "service projects" (definition: a project which exposes a REST API?) are "integrated projects" and that's what's contained in our release. I think we also say that Oslo libraries are part of the integrated release. The way I see it, our release is a product and should contain any official OpenStack software which provides a more complete experience for people deploying OpenStack clouds. The only change that would mean right now is that the client libraries and docs would be part of the integrated release. Even if there are some wonky details - like we have good reason to *also* release clients independently of the release cycle for a different set of target users (i.e. cloud users, not cloud builders) and that complete docs aren't a blocker for the integrated release going out - I think the release is weirdly incomplete without those considered a part of it. Also, before any jumps in with "we shouldn't have releases, trunk should always be releasable" ... that's mostly orthogonal. We'd still have a concept of an integrated product - which includes more than just the server products - which is always releaseable. _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
