Open Stack

On Wed, May 30, 2018 at 6:09 PM, Matthew Treinish <mtreinish at kortar.org> wrote:
> On Thu, May 31, 2018 at 12:21:35AM +0000, Fox, Kevin M wrote:
>> To play devils advocate and as someone that has had to git bisect an ugly regression once I still think its important not to break trunk. It can be much harder to deal with difficult issues like that if trunk frequently breaks.
>>
>> Thanks,
>> Kevin
>> ________________________________________
>> From: Sean McGinnis [sean.mcginnis at gmx.com]
>> Sent: Wednesday, May 30, 2018 5:01 PM
>> To: openstack-dev at lists.openstack.org
>> Subject: Re: [openstack-dev] [tc][all] A culture change (nitpicking)
>>
>> > "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.

>
> -Matt Treinish
>
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>



-- 
Davanum Srinivas :: https://twitter.com/dims