[openstack-dev] incubating diskimage-builder?

Thierry Carrez thierry at openstack.org
Thu May 30 08:55:56 UTC 2013


Mark McLoughlin wrote:
> I can accept that Oslo's scope is a *little* nebulous, but some of the
> things which I think defines Oslo's scope is:
> 
>   - addressing cross-project technical debt
>   - python code which would historically have been across official
>     OpenStack projects
>   - building a set of python libraries focused on the needs of official 
>     OpenStack projects
>   - oslo-core, as a group of python generalists with an interest in 
>     clean APIs, are good reviewers for the code
> 
> Honestly, even at a stretch, I don't think Oslo is the right umbrella to
> have d-i-b under.

Yeah, I originally thought it was Python code that would end up being
used by multiple projects, but it's mostly utility shell scripts so the
rootwrap (or pbr) precedents can't really be used as a reason.

> This process of trying to find somewhere to shoehorn d-i-b feels wrong
> to me. If it belongs in OpenStack now, it coming in as a new standalone
> thing shouldn't be a problem. Applying for incubation would make TC
> members give you properly considered feedback.

I think we could first have an open discussion at the next TC meeting
(Tuesday) to see where we think this best belongs. No need to formally
apply for incubation if we decide it belongs outside OpenStack
integrated release.

> Where we get ourselves tied up into knots is trying to figure out which
> category it with fit into here:
> 
>   https://wiki.openstack.org/wiki/Projects
> 
> and whether it would be in a category that would have a PTL that
> automatically gets a TC seat.
> 
> And, well ... I'm not a big fan of such rigid categorization because I
> don't think it really helps much and it does constrain us in cases such
> as this ... and I'm not a big fan of PTLs automatically having TC seats,
> because it bears too much on the consideration of new projects.

The main reason for this rigid categorization is due to the current TC
composition: we had to have "projects with PTLs which give automatic TC
seats" and "other official projects that may have PTLs but wouldn't get
TC seats". As discussed elsewhere, that doesn't scale well nor does it
encourage adding/splitting projects as would be technically appropriate.

But until we change those TC membership rules (see thread at [1] if
interested in that discussion), we kinda have to categorize projects,
and this one falls a bit between the lines.

[1]
http://lists.openstack.org/pipermail/openstack-dev/2013-May/009578.html

-- 
Thierry Carrez (ttx)
Release Manager, OpenStack



More information about the OpenStack-dev mailing list