Open Stack

On Sun, Aug 18, 2013 at 11:17 PM, Robert Collins
<robertc at robertcollins.net>wrote:

> 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
>

Not at all, perhaps I was missing something in your proposal.  If you're
proposing we "do something the way we're already doing it" I've obvioulsy
missed something, or read into things somewhere that perhaps I shouldn't
have.


> > 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.
>

Just to be clear, I'm not arguing against smaller multiple change-sets, I
believe as do most that these are better for quite a few reasons.  I'm just
saying that I'm not sure about the idea of trying to assign a number right
now.  To be fair it's pretty easy to burn through say 500 lines of code
when implementing a feature in OpenStack, between all the wrappers and
adding unit-tests and hopefully some comments, that diff grows pretty
quickly.


>
> >  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.
>

Sure, I don't think it's perfect by any means but I do think attempts are
being made.

>
> >  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.
>

Pheww... ok, perhaps I misunderstood things here, in which case I'll go
back about my business.

>
> - 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.
>

Thanks for the clarification here, I wasn't really sure what your intent
was so I'm glad that you pointed it out here.  Looking forward to the
session on this in 12 weeks and how the conversation proceeds between now
and then.

>
> -Rob
>
>
>
> --
> Robert Collins <rbtcollins at hp.com>
> Distinguished Technologist
> HP Converged Cloud
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20130819/eb2f574f/attachment.html>