Open Stack

On Wed, May 1, 2013 at 8:03 AM, Clint Byrum <clint at fewbar.com> wrote:

> On 2013-04-30 14:52, Russell Bryant wrote:
>
>> 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.
>>
>
> 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.


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.

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.

Chris
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20130501/b8d1f2c3/attachment.html>