<div dir="ltr"><div class="gmail_default" style="font-family:courier new,monospace"><br></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Sun, Aug 18, 2013 at 11:17 PM, Robert Collins <span dir="ltr"><<a href="mailto:robertc@robertcollins.net" target="_blank">robertc@robertcollins.net</a>></span> wrote:<br>

<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">On 19 August 2013 16:15, John Griffith <<a href="mailto:john.griffith@solidfire.com">john.griffith@solidfire.com</a>> wrote:<br>


<br>
> This was pretty well discussed back in April and May IMO.<br>
<br>
</div>It petered out with no firm consensus AFAICT. Those of us with CD<br>
experience are trying to debug the concerns those of us here without<br>
CD experience have, so that we can bring the benefits in.<br>
<div class="im"><br>
> Suffice it to say, I'm very much against the idea of 'disabled features'<br>
> landing in trunk,<br>
<br>
</div>Ok. So you don't like how the Nova V3 API was done then? Or the new<br>
keystone API? Or is your objection to code<br></blockquote><div><br></div><div class="gmail_default" style="font-family:'courier new',monospace">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.</div>

<div class="gmail_default" style="font-family:'courier new',monospace"><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="im"><br>
> and I'm also not a fan of the idea of an arbitrary max<br>
> lines of code per patch set.<br>
<br>
</div>Once I would have said this, but there is now research into the size<br>
of change <-> defect rate. The limits proposed are not arbitrary: they<br>
are evidence based.<br></blockquote><div><br></div><div class="gmail_default" style="font-family:'courier new',monospace">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.</div>

<div class="gmail_default" style="font-family:'courier new',monospace">   </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="im"><br>
>  A number of folks have pointed out that we're<br>
> getting better at things like "feature-rush" at the end of a cycle and our<br>
> own community "best practices" enforcement on patch size.<br>
<br>
</div>That claim has been made. I think we should do a retrospective after H<br>
releases to see if it is fact, or wish ;). A growing contributor base<br>
and long review lead times may counter the policy based approach taken<br>
in this cycle. Either way we'll still have a freeze period to deal<br>
with, with it's downsides.<br></blockquote><div><br></div><div class="gmail_default" style="font-family:'courier new',monospace">Sure, I don't think it's perfect by any means but I do think attempts are being made.</div>

<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="im"><br>
>  I think that<br>
> model works well in an Open Source environment, particularly one the size of<br>
> OpenStack with the varied interest and participation.<br>
<br>
</div>I think that the model we're converging on for CD in OpenStack will<br>
work well too; but we need to experiment a bit once the constraints<br>
are known to really know.<br></blockquote><div> <br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="im"><br>
> IMO intentionally placing non-working (and thereby useless code as far as<br>
> I'm concerned) in the project with no testing, no documentation and worst of<br>
> all no guarantee that anybody is ever going to work on said code again is a<br>
> bad idea.<br>
<br>
</div>When you say it like that I don't want this either!. Fortunately that<br>
isn't *at all* what is being proposed.<br></blockquote><div><br></div><div class="gmail_default" style="font-family:'courier new',monospace">Pheww... ok, perhaps I misunderstood things here, in which case I'll go back about my business.</div>

<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
- non-working: *none* of the proposals have proposed non-working code.<br>
- testing: *none* of the proposals have proposed any exception to<br>
testing policies - all the code should be tested.<br>
- documentation: Likewise, all the code should be documented, and as<br>
the feature becomes accessible to early adopters, *obviously* user<br>
documentation should be present.<br>
- guarantees that someone will work on a feature: We have no guarantee<br>
that we'll ever receive another hyper-V patch. In fact, we have no<br>
guarantees for any feature that anyone will work on it again, whether<br>
or not the feature is 'complete'. A better question might be: does<br>
someone with an incomplete feature, or a complete feature, have more<br>
motivation to keep working on it?<br>
<div class="im"><br>
> The explosive growth of what OpenStack is and all of the projects<br>
> is pretty difficult for folks to get wrapped around already, let alone if we<br>
> start having this unbelievable matrix of flags, paralell features etc.<br>
<br>
</div>What new unbelievable matrix are you referring to? We already have a<br>
huge matrix of features, with no structure or introspection visible,<br>
and a solid system for managing new ones coming would make landing<br>
large things like cells much less disruptive.<br>
<div class="im"><br>
> Anyway, a number of postings are no longer tracked in this thread it seems,<br>
> but there have been statements from Russell B, Thierry and Michael Still<br>
> that I strongly agree with here.<br>
<br>
</div>What I'm trying to do at this point is capture those concerns<br>
accurately so they can be addressed. If we're going to have a<br>
productive step forward on this - e.g. another session at the summit,<br>
we need to go in with as many concerns captured as possible. Last time<br>
we had a great session, and then an 'omg what' reaction here, in this<br>
list.<br></blockquote><div><br></div><div class="gmail_default" style="font-family:'courier new',monospace">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.</div>

<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="im HOEnZb"><br>
-Rob<br>
<br>
<br>
<br>
--<br>
Robert Collins <<a href="mailto:rbtcollins@hp.com">rbtcollins@hp.com</a>><br>
Distinguished Technologist<br>
HP Converged Cloud<br>
<br>
</div><div class="HOEnZb"><div class="h5">_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</div></div></blockquote></div><br></div></div>