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)
__________________________________________________________________________
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
