<div dir="ltr"><br><div class="gmail_extra"><div class="gmail_quote">On Wed, May 1, 2013 at 8:03 AM, Clint Byrum <span dir="ltr"><<a href="mailto:clint@fewbar.com" target="_blank">clint@fewbar.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5">On 2013-04-30 14:52, Russell Bryant wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
On 04/30/2013 04:59 PM, Clint Byrum wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
On 2013-04-30 13:12, Sean Dague wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
On 04/30/2013 03:55 PM, Clint Byrum wrote:<br>
<snip><br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
I understand that this is a straw-man. I know that other things can<br>
happen. But I see a lot of development happen under the stable release<br>
process scenario above. I fail to see where having new code arrive<br>
incrementally in small batches and protected by feature flags is going<br>
to make anything worse. Those things, however, should make continuous<br>
delivery of OpenStack much smoother.<br>
</blockquote>
<br>
Right, it's a straw man, which doesn't help generate any clarity. :)<br>
<br>
I think instead of discussing philosophy here we should talk about<br>
specifics that happened in the source tree that caused deployers pain,<br>
and take lessons learned out of them.<br>
<br>
I think the reality is that openstack tree and process is very close<br>
to what the CD folks want. The only thing that's causing some allergy<br>
among the core teams is the idea of features coming in in an off<br>
state, versus coming in default on so they get exercised by our normal<br>
system.<br>
<br>
</blockquote>
<br>
Thats exactly my point. Large changes are not being exercised by any<br>
large scale system now while they're baking in a branch, so making them<br>
enabled by feature flags versus by commit to trunk does not regress<br>
that, but it does allow deployers to test both code paths and deploy<br>
both without having to maintain branches of the software.<br>
</blockquote>
<br>
My biggest concern with this is applying it to an open source project<br>
with an unmanaged workforce.  Thierry captured it well when he said:<br>
<br>
  Personally my experience of OpenStack project management makes me fear<br>
  that your proposal ignores the reality of our unmanaged development<br>
  workforce: there is no way we can be sure that a feature will actually<br>
  be completed. So you might end up having disabled code in releases...<br>
  or force the removal of the already-landed parts at the very last<br>
  moment, which is disruptive to release quality and also sounds more<br>
  disruptive to CD than what you are trying to protect against.<br>
<br>
I'm really worried about the transition of ownership going from the<br>
submitter to the project as a whole much earlier in the process.  I'd<br>
like to have a high confidence level that it's worth having this code<br>
for the long run before it starts coming in.  That to me requires it<br>
baking out of tree and getting completed before we accept it.<br>
</blockquote>
<br></div></div>
What is the negative impact of having disabled code in a release? I think we would need a good reason before we would back accepted code out. If the code is just sitting there, undocumented and turned off, not interfering with anything, I'm having a hard time thinking of a logical reason to back it out.</blockquote>
<div> </div><div>Having  a lot of disabled code makes it much harder to do various cleanups which cross a lot of code. People end up spending time trying to adapt solutions for code which is hardly used or not used at all.<br>
<br></div><div>I'm not a fan of having lots of enabling/disabling switches either. Even if we accept new features initially with a disable switch I think the aim in most cases should be to remove that switch before a release is made. Otherwise long term we end up with a maze of switches with potentially complicated dependencies between them.<br>
<br></div><div>Chris<br></div></div></div></div>