Open Stack

On Thu, 2013-05-30 at 13:17 +1200, Robert Collins wrote:
> On 27 May 2013 21:57, Thierry Carrez <thierry at openstack.org> wrote:
> > Robert Collins wrote:
> >> Diskimage-builder isn't a whole lot of code, but thats deliberate ;).
> >> It is however something I suspect will end up in the inner loop of a
> >> bunch of projects as people get familiar with it's utility. Maybe it
> >> should be an oslo component  [though its 95% shell], or maybe it
> >> should be 'part of' glance in the same way python-glanceclient is
> >> 'part of' glance.
> >
> > I think it makes sense as an Oslo component, exactly for the same
> > reasons rootwrap is an Oslo component. Both are small, 95% shell, and
> > end up in the inner loop of a bunch of OpenStack projects...
> >
> > Oslo already has a concept of "specialist maintainer" so you can keep
> > driving it.
> 
> Hi Mark; I think Thierry's suggestion of Oslo components makes sense.
> Could you have a look at
> https://github.com/stackforge/diskimage-builder and weigh in on what
> you think the best route forward for this is?

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.

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.

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.

Cheers,
Mark.