Open Stack

On 04/30/2013 04:59 PM, Clint Byrum wrote:
> On 2013-04-30 13:12, Sean Dague wrote:
>> On 04/30/2013 03:55 PM, Clint Byrum wrote:
>> <snip>
>>>
>>> I understand that this is a straw-man. I know that other things can
>>> happen. But I see a lot of development happen under the stable release
>>> process scenario above. I fail to see where having new code arrive
>>> incrementally in small batches and protected by feature flags is going
>>> to make anything worse. Those things, however, should make continuous
>>> delivery of OpenStack much smoother.
>>
>> Right, it's a straw man, which doesn't help generate any clarity. :)
>>
>> I think instead of discussing philosophy here we should talk about
>> specifics that happened in the source tree that caused deployers pain,
>> and take lessons learned out of them.
>>
>> I think the reality is that openstack tree and process is very close
>> to what the CD folks want. The only thing that's causing some allergy
>> among the core teams is the idea of features coming in in an off
>> state, versus coming in default on so they get exercised by our normal
>> system.
>>
> 
> Thats exactly my point. Large changes are not being exercised by any
> large scale system now while they're baking in a branch, so making them
> enabled by feature flags versus by commit to trunk does not regress
> that, but it does allow deployers to test both code paths and deploy
> both without having to maintain branches of the software.

My biggest concern with this is applying it to an open source project
with an unmanaged workforce.  Thierry captured it well when he said:

  Personally my experience of OpenStack project management makes me fear
  that your proposal ignores the reality of our unmanaged development
  workforce: there is no way we can be sure that a feature will actually
  be completed. So you might end up having disabled code in releases...
  or force the removal of the already-landed parts at the very last
  moment, which is disruptive to release quality and also sounds more
  disruptive to CD than what you are trying to protect against.

I'm really worried about the transition of ownership going from the
submitter to the project as a whole much earlier in the process.  I'd
like to have a high confidence level that it's worth having this code
for the long run before it starts coming in.  That to me requires it
baking out of tree and getting completed before we accept it.

-- 
Russell Bryant