Open Stack

On 19 August 2013 16:15, John Griffith <john.griffith at solidfire.com> wrote:

> This was pretty well discussed back in April and May IMO.

It petered out with no firm consensus AFAICT. Those of us with CD
experience are trying to debug the concerns those of us here without
CD experience have, so that we can bring the benefits in.

> Suffice it to say, I'm very much against the idea of 'disabled features'
> landing in trunk,

Ok. So you don't like how the Nova V3 API was done then? Or the new
keystone API? Or is your objection to code

> and I'm also not a fan of the idea of an arbitrary max
> lines of code per patch set.

Once I would have said this, but there is now research into the size
of change <-> defect rate. The limits proposed are not arbitrary: they
are evidence based.

>  A number of folks have pointed out that we're
> getting better at things like "feature-rush" at the end of a cycle and our
> own community "best practices" enforcement on patch size.

That claim has been made. I think we should do a retrospective after H
releases to see if it is fact, or wish ;). A growing contributor base
and long review lead times may counter the policy based approach taken
in this cycle. Either way we'll still have a freeze period to deal
with, with it's downsides.

>  I think that
> model works well in an Open Source environment, particularly one the size of
> OpenStack with the varied interest and participation.

I think that the model we're converging on for CD in OpenStack will
work well too; but we need to experiment a bit once the constraints
are known to really know.

> IMO intentionally placing non-working (and thereby useless code as far as
> I'm concerned) in the project with no testing, no documentation and worst of
> all no guarantee that anybody is ever going to work on said code again is a
> bad idea.

When you say it like that I don't want this either!. Fortunately that
isn't *at all* what is being proposed.

- non-working: *none* of the proposals have proposed non-working code.
- testing: *none* of the proposals have proposed any exception to
testing policies - all the code should be tested.
- documentation: Likewise, all the code should be documented, and as
the feature becomes accessible to early adopters, *obviously* user
documentation should be present.
- guarantees that someone will work on a feature: We have no guarantee
that we'll ever receive another hyper-V patch. In fact, we have no
guarantees for any feature that anyone will work on it again, whether
or not the feature is 'complete'. A better question might be: does
someone with an incomplete feature, or a complete feature, have more
motivation to keep working on it?

> The explosive growth of what OpenStack is and all of the projects
> is pretty difficult for folks to get wrapped around already, let alone if we
> start having this unbelievable matrix of flags, paralell features etc.

What new unbelievable matrix are you referring to? We already have a
huge matrix of features, with no structure or introspection visible,
and a solid system for managing new ones coming would make landing
large things like cells much less disruptive.

> Anyway, a number of postings are no longer tracked in this thread it seems,
> but there have been statements from Russell B, Thierry and Michael Still
> that I strongly agree with here.

What I'm trying to do at this point is capture those concerns
accurately so they can be addressed. If we're going to have a
productive step forward on this - e.g. another session at the summit,
we need to go in with as many concerns captured as possible. Last time
we had a great session, and then an 'omg what' reaction here, in this
list.

-Rob



-- 
Robert Collins <rbtcollins at hp.com>
Distinguished Technologist
HP Converged Cloud