On Wed, May 30, 2018 at 6:09 PM, Matthew Treinish <mtrein...@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.mcgin...@gmx.com] >> Sent: Wednesday, May 30, 2018 5:01 PM >> To: openstack-dev@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-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > -- Davanum Srinivas :: https://twitter.com/dims __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev