On 19 August 2013 16:15, John Griffith <john.griff...@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 <rbtcoll...@hp.com> Distinguished Technologist HP Converged Cloud _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev