Open Stack

On Fri, 2014-09-05 at 08:02 -0400, Sean Dague wrote:
> On 09/05/2014 07:40 AM, Daniel P. Berrange wrote:
> > On Fri, Sep 05, 2014 at 07:12:37AM -0400, Sean Dague wrote:
> >> On 09/05/2014 06:40 AM, Nikola Đipanov wrote:
> >>> A handy example of this I can think of is the currently granted FFE for
> >>> serial consoles - consider how much of the code went into the common
> >>> part vs. the libvirt specific part, I would say the ratio is very close
> >>> to 1 if not even in favour of the common part (current 4 outstanding
> >>> patches are all for core, and out of the 5 merged - only one of them was
> >>> purely libvirt specific, assuming virt/ will live in nova-common).
> >>>
> >>> Joe asked a similar question elsewhere on the thread.
> >>>
> >>> Once again - I am not against doing it - what I am saying is that we
> >>> need to look into this closer as it may not be as big of a win from the
> >>> number of changes needed per feature as we may think.
> >>>
> >>> Just some things to think about with regards to the whole idea, by no
> >>> means exhaustive.
> >>
> >> So maybe the better question is: what are the top sources of technical
> >> debt in Nova that we need to address? And if we did, everyone would be
> >> more sane, and feel less burnt.
> >>
> >> Maybe the drivers are the worst debt, and jettisoning them makes them
> >> someone else's problem, so that helps some. I'm not entirely convinced
> >> right now.
> >>
> >> I think Cells represents a lot of debt right now. It doesn't fully work
> >> with the rest of Nova, and produces a ton of extra code paths special
> >> cased for the cells path.
> >>
> >> The Scheduler has a ton of debt as has been pointed out by the efforts
> >> in and around Gannt. The focus has been on the split, but realistically
> >> I'm with Jay is that we should focus on the debt, and exposing a REST
> >> interface in Nova.
> >>
> >> What about the Nova objects transition? That continues to be slow
> >> because it's basically Dan (with a few other helpers from time to time).
> >> Would it be helpful if we did an all hands on deck transition of the
> >> rest of Nova for K1 and just get it done? Would be nice to have the bulk
> >> of Nova core working on one thing like this and actually be in shared
> >> context with everyone else for a while.
> > 
> > I think the idea that we can tell everyone in Nova what they should
> > focus on for a cycle, or more generally, is doomed to failure. This
> > isn't a closed source company controlled project where you can dictate
> > what everyones priority must be. We must accept that rely on all our
> > contributors good will in voluntarily giving their time & resource to
> > the projct, to scratch whatever itch they have in the project. We have
> > to encourage them to want to work nova and demonstrate that we value
> > whatever form of contributor they choose to make. If we have technical
> > debt that we think is important to address we need to illustrate /
> > show people why they should care about helping. If they none the less
> > decide that work isn't for them, we can't just cast them aside and/or
> > ignore their contributions, while we get on with other things. This
> > is why I think it is important that we split up nova to allow each
> > are to self-organize around what they consider to be priorities in
> > their area of interest / motivation. Not enabling that is going to
> > to continue to kill our community
> 
> I'm getting tired of the reprieve that because we are an Open Source
> project declaring priorities is pointless, because it's not. I would say
> it's actually the exception that a developer wakes up in the morning and
> says "I completely disregard what anyone else thinks is important in
> this project, this is what I'm going to do today". Because if that's how
> they felt they wouldn't choose to be part of a community, they would
> just go do their own thing. Lone wolfs by definition don't form
> communities.

Actually, I don't think this analysis is accurate.  Some people are
simply interested in small aspects of a project.  It's the "scratch your
own itch" part of open source.  The thing which makes itch scratchers
not lone wolfs is the desire to go the extra mile to make what they've
done useful to the community.  If they never do this, they likely have a
forked repo with only their changes (and are the epitome of a lone
wolf).  If you scratch your own itch and make the effort to get it
upstream, you're assisting the community (even if that's the only piece
of code you do) and that assistance makes you (at least for a time) part
of the community.

A community doesn't necessarily require continuity from all its
elements.  It requires continuity from some (the core, if you will), but
it also allows for contributions from people who only have one or two
things they need doing.  For OpenStack to convert its users into its
contributors, it is going to have to embrace this, because they likely
only need a couple of things fixing, so they'll pop into the community,
fix what they need fixing and then go back to being users again.

Some projects, the linux kernel in particular, deliberately don't
enforce priorities on the contributors.  Priorities are effectively
given by the eagerness of the contributors to get upstream and their
willingness to make the contribution acceptable to upstream.  I'm not
saying this is the only (or even the best) way to run a project, but it
does demonstrate that the self organizing nature of communities can be
harnessed to produce forward momentum.

James