Am 18.04.2018 um 15:07 schrieb Jim Jagielski:
There are, IMO at least, 3 types of "regression" that we should be concerned about or that some people are concerned about:1. New features: Undoubtedly, new features will likely have bugs and no by adding new features we could be adding bugs which could be seen as a regression. 2. Simple fixes: A simple fix causes a regression. 3. Wholesale refactoring: IMO, this is the one which is the most problematic for us lately. We have seen several cases where a simple bug or a desire to "make this part of the code better" has resulted in huge amounts of code churn, major rewrites and major refactoring. My PoV is that: o We need to continue to add new features. We must provide better QA and testing. o We need to avoid our natural inclinations to look at "fixing bugs" as an opportunity for major refactors. If people want to major refactor, fine. But that stays in trunk. What is important is that we patch the bug 1st. Premature re-factoring is as bad as premature optimization.
Since this thread was triggered by the mod_ssl config merging problems: I think that was a case where a new feature was really nice, but to implement it the needed changes where not not easy to understand in detail. Combined with the complex behavior of mod_ssl w.r.t. config merging we ended up with unexpected config merging problems. So that specific problem belongs to your class 1 (I think both, the one detected by Mark Blackman and the one received via Joe).
It is not a total surprise, that regressions - be it due to features, bug fixing or refactoring - most often happen in mod_proxy or mod_ssl. These are IMHO by far the most complex modules (together with the event MPM). Unfortunately the same parts are very attractive for features, so we have some need to touch them.
When implementing a feature or fixing a bug it is often hard to decide where the border is crossed that makes a change a "major" refactoring or whether a changes still mostly helps to understand the code.
We do lack a robust procedure and resources for testing complex configurations and also testing on many platforms. I don't have a solution for that :(
More release branches would only help, if people would actually pick them up. So we would need to keep features in the higher branches at least for a noticeable time. Of course the enterprise distros would not pick the additional release branches up, but maybe if they have attractive features, they might get picked up by faster moving distros, inside container images and by 3rd-parties like Apache Lounge. We could even provide builds for some platforms as a voluntary service.
All in all I'd prefer an attempt to have a faster moving 2.6 and a stable backport branch 2.4 real soon.
Regards, Rainer
