httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jacob Champion <>
Subject Re: [proposed] 2.4 Maintenance SIG
Date Thu, 19 Jan 2017 20:12:40 GMT
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*.


View raw message