Open Stack

Davanum Srinivas wrote:
>>>> "master should be always deployable and fully backward compatible and
>>>> so we cant let anything in anytime that could possibly regress anyone"
>>>>
>>>> Should we change that attitude too? Anyone agree? disagree?
>>>>
>>>> Thanks,
>>>> Dims
>>>>
>>> I'll definitely jump at this one.
>>>
>>> I've always thought (and shared on the ML several times now) that our
>>> implied
>>> but not explicit support for CD from any random commit was a bad thing.
>>>
>>> While I think it's good to support the idea that master is always
>>> deployable, I
>>> do not think it is a good mindset to think that every commit is a
>>> "release" and
>>> therefore should be supported until the end of time. We have a coordinated
>>> release for a reason, and I think design decisions and fixes should be
>>> based on
>>> the assumption that a release is a release and the point at which we
>>> need to be
>>> cognizant and caring about keeping backward compatibility. Doing that for
>>> every single commit is not ideal for the overall health of the product, IMO.
>>>
>>
>> It's more than just a CD guarantee, while from a quick glance it would seem like
>> that's the only value it goes much deeper than that. Ensuring that every commit
>> works, is deployable, and maintains backwards compatibility is what enables us
>> to have such a high quality end result at release time. Quite frankly it's
>> looking at every commit as always being a working unit that enables us to manage
>> a project this size at this velocity. Even if people assume no one is actually
>> CDing the projects(which we shouldn't), it's a flawed assumption to think that
>> everyone is running strictly the same code as what's in the release tarballs. I
>> can't think of any production cloud out there that doesn't carry patches to fix
>> things encountered in the real world. Or look at stable maint we regularly need
>> to backport fixes to fix bugs found after release. If we can't rely on these to
>> always work this makes our life much more difficult, both as upstream
>> maintainers but also as downstream consumers of OpenStack.
>>
>> The other aspect to look at here is just the review mindset, supporting every
>> every commit is useable puts reviewers in the mindset to consider things like
>> backwards compatibility and deployability when looking at proposed changes. If
>> we stop looking for these potential issues, we t will also cause many more bugs
>> to be in our released code. To simply discount this as only a release concern
>> and punt this kind of scrutiny until it's time to release is not only going to
>> make release time much more stressful. Also, our testing is built to try and
>> ensure every commit works **before** we merge it. If we decided to take this
>> stance as a community then we should really just rip out all the testing,
>> because that's what it's there to verify and help us make sure we don't land a
>> change that doesn't work. If we don't actually care about that making sure every
>> commit is deployable we are wasting quite a lot of resources on it.
> 
> "rip out all testing" is probably taking it too far Matt.
> 
>   Instead of perfection when merging, we should look for iteration and
> reverts. That's what i would like to see. I am not asking for a
> "Commit-Then-Review" like the ASF. I want us to be just be practical
> and have some leeway to iterate / update / experiment instead of
> absolute perfection from all angles. We should move the needle at
> least a bit away from it.

Right... There might be a reasonable middle ground between "every commit 
on master must be backward-compatible" and "rip out all testing" that 
allows us to routinely revert broken feature commits (as long as they 
don't cross a release boundary).

To be fair, I'm pretty sure that's already the case: we did revert 
feature commits on master in the past, therefore breaking backward 
compatibility if someone started to use that feature right away. It's 
the issue with implicit rules: everyone interprets them the way they 
want... So I think that could use some explicit clarification.

[ This tangent should probably gets its own thread to not disrupt the 
no-nitpicking discussion ]

-- 
Thierry Carrez (ttx)