<div dir="ltr">On Tue, Apr 30, 2013 at 7:58 AM, Joe Gordon <span dir="ltr"><<a href="mailto:jogo@cloudscaling.com" target="_blank">jogo@cloudscaling.com</a>></span> wrote:<br><div class="gmail_extra"><div class="gmail_quote">
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><span style="color:rgb(80,0,80)">On Mon, Apr 29, 2013 at 2:04 PM, Robert Collins </span><span dir="ltr" style="color:rgb(80,0,80)"><<a href="mailto:robertc@robertcollins.net" target="_blank">robertc@robertcollins.net</a>></span><span style="color:rgb(80,0,80)"> wrote:</span><div class="gmail_extra">
<div class="gmail_quote"><div class="im"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<br>
 * No more cramming: when a freeze is happening, anything that is<br>
'land this for the release' has to be pushed back on -really hard-. If<br>
its not ready, it's not ready.<br></blockquote><div><br></div></div><div>Has this been an issue recently? I thought we were getting better with this.</div></div></div></div></blockquote><div><br></div><div style>Agreed. Russell's introduction of a feature proposal deadline is the next logical step in being more mature here. I don't think we need to make specific further changes at this time.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div class="im"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
 * Land features disabled by default. Such disabled features are<br>
experimental and we don't need to be so careful - we can in fact<br>
remove them entirely if they turn out to be bad idea - when they<br>
become supported (individual teams can define this we think) they<br>
can't be broken again though: they are now part of the product.<br></blockquote><div><br></div></div><div>This touches on a bigger issue, what is experimental and what is not.  Currently we don't do a good job of differentiating the two.  I think we first need to flesh out what it means to be experimental for users and for development.</div>
</div></div></div></blockquote><div><br></div><div style> I strongly disagree with landing features off by default. There are a few reasons for that:</div><div style><br></div><div style> - we've been moving away from "make it work" flags. This moves us in the other direction -- we proliferate flags, many of which might be required to make nova work well in real deployments. These extra flags also make the codebase more complicated, and therefore less safe to develop in.</div>
<div style><br></div><div style> - it results in untested code in the codebase (untested in the sense of undeployed by any real deployment). This means we end up with a false sense of security about the stability of that code until we eventually turn it on by default. Then we discover no one has used it before and that its totally broken.</div>
<div style><br></div><div style>From my selfish upstream perspective, the purpose of CD is to help us find errors before they hit large numbers of deployments. That's why we should be so grateful to Rackspace, HP, or anyone else willing to run trunk -- that testing is invaluable and comes at a cost for the deployer. We should be doing everything we can to ensure brokenness is found early, even if that means slightly more pain for deployers.</div>
<div style><br></div><div style>Michael</div></div></div></div>