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. 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?
