Am 18.04.2018 um 18:07 schrieb William A Rowe Jr:
On Wed, Apr 18, 2018 at 10:57 AM, Rainer Jung <rainer.j...@kippdata.de> wrote:
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.
Keep in mind Windows has been broken on nearly every release,
recently in the core and mod_ssl build. So although I forked an SSL
regression thread, please don't read into this that they are primary
"culprits"... even core changes broke mod_security.
You are right, windows builds is also a fragile area. Not because the
builds themselves are fragile, but many of us do not have them in their
focus.
I am not blaming either proxy+ssl modules, nor their developers.
I'm raising process issues, not contribution or contributor issues.
Looking for a scheme to let contributors shine by putting our code
enhancements and major refactoring through a community review
process, which has been neglected for most of this decade.
All in all I'd prefer an attempt to have a faster moving 2.6 and a stable
backport branch 2.4 real soon.
Question, if 2.6 is moving "fast", and handled as 2.4 was, is there any
net benefit for better releases? What can we agree to in versioning
prior to 2.6.x-GA that will ease the process for contributors, external
module authors, distributors and users?
I would expect people picking up 2.6 to be in a better position doing
frequent updates and having a bit higher tolerance for an occasional
break as the downside of getting new features quickly.
So people could choose: stick to the slowly moving 2.4 branch (and get
it from the enterprise distro vendor) or switch to the faster moving 2.6
with the downside of a higher risk in regressions and using a different
source for the binaries (or of course build themselves).
Regards,
Rainer
