On 01/19/2017 07:49 AM, Jim Jagielski wrote:
You seem to be ignoring the times when bug-fixes, and regression-fix-only patches themselves have resulted in regressions.
Sure, that does (and will continue to) happen. Every code change carries some risk, and no test suite is 100% perfect, but I don't think that's a reason not to separate bugfix and feature releases. (Plus, in my experience, the projects who ship bugfix lines tend to also be very quick about reverting bad fixes and immediately re-releasing when they accidentally break something else.)
It's a matter of risk management. If you know that every code change carries a non-zero risk of breaking deployments, and you separate low-risk changes (bugfixes) from higher-risk changes (functionality additions), then both end users and distro maintainers have a better time keeping up and managing their own risk. And different end users have different definitions of which risks are acceptable at which times.
Now, to your point about testing: a strong test suite shifts the entire risk "curve", so that functionality changes are safer to ship alongside bugfixes. So yes, I agree with you and we absolutely need to move in that direction. I've been trying to put my money where my mouth is there. But we're not there yet, and that means that many end users will view our functionality improvements as higher-risk. Rightly so IMO.
Even after we strengthen our test suite, there will still be value to end users in separating bugfix and feature releases, because it lets them decide what risks they're willing to take. What the test suite gives us then is the ability to roll out feature releases faster and faster without fear of regressions, so the lifetime of the low-risk bugfix lines can be shorter. It all feeds back, and everyone gets happier, and we can focus on cool stuff more.
Or when bug-fixes themselves devolve into grand-scale refactoring which greatly introduce the very real probability of regressions.
Typically a bugfix release line wouldn't be receiving refactoring patches, just the smallest changes possible to fix bugs. The refactoring would happen in the feature release line.
(And the refactoring itself shouldn't be mixing code motion with functional changes to begin with; that's like rule #1. :) )
Handling regressions seems independent from where they come from. Again, if we wish to release something quick that just includes patches-as-of-this-date, then we certainly can. But the 2 are not as tied-at-the-hip as you make it to be.
I don't agree with everything Bill is saying here, but to be fair to him: if people are backporting new features and higher-risk changes to 2.4.x at the same time an RM is trying to coordinate a bugfix-only release, I would imagine that would be fairly difficult for *everyone*.
--Jacob
