On Wed, Apr 18, 2018 at 8:01 AM, Stefan Eissing <stefan.eiss...@greenbytes.de> wrote: > > >> Am 17.04.2018 um 19:18 schrieb William A Rowe Jr <wr...@rowe-clan.net>: >> >>> The architecture of v2.4 has been very stable, the need for breaking >>> changes has been largely non existent, and the focus since 2011 has been to >>> get changes backported to v2.4 instead. >>> >>> To distill this down to raw numbers, there have been 1546 discrete >>> backports (my simple grep of CHANGES) since 2011 - which has provided an >>> enormous amount of enhancement for the collective community’s scrutiny. >> >> And the corresponding number of regressions and behavior changes. None >> of these have enjoyed an "RC" or "beta", whatever one calls it, to >> validate before adoption - other than our claim of "best httpd yet". >> It has been an entirely new kitchen sink on every subversion release. > > All my substantial functional additions had beta releases for months before > being voted into the 2.4.x branch. With binary beta packages available for > several platforms by several supporters. > > William, this painting our world a dark and miserable place is coming back > every few months. It is a disservice to the people who contribute changes > here.
I hate to break this to you, and I do not want to discredit the amazing work all the contributors here are doing, but httpd 2.4 is of miserable, miserable quality when it comes to breaks and regressions. I maintain the PHP/Apache/Nginx infrastructure at Heroku, and I was able to use the following httpd releases only in the last ~2.5 years: - 2.4.16 - 2.4.18 - 2.4.20 - 2.4.29 -2.4.33 Mostly because of regressions around mod_proxy(_fcgi), REDIRECT_URL, whatever. This is not any person's fault. This is the fault of the process. The process can be repaired: bugfixes only in 2.4.x, do RC cycles for bugfix releases as well (that alone makes the changelog look a lot less confusing, which is useful for the project's image, see also the Nginx marketing/FUD discussion in the other thread), and start testing new features in modules first. It makes such little sense to land h2 support in 2.4.something, as opposed to having it as an official "brand new, try it out" subproject first, and then bundle it with 2.6. Speaking of which, I'd also suggest dropping this odd/even number meaning experimental/stable versioning scheme, since it only aggravates the problem: never-ending experiments that go stale, maybe even get half backported, and meanwhile are subconsciously perceived as one more hurdle towards a next bigger release. Really, I'd suggest taking a close look at the PHP release cycle, with their schedules, their RFC policies, everything. As I said in that other thread, the PHP project was in exactly the same spot a few years ago and they have pulled themselves out of that mess with amazing results. I am also happy to make introductions to release managers and maintainers there. Heck I am betting some of them would happily serve as tutors for the httpd project ;) I'm certainly willing to help too. But IMO you need a clean cut and shake up the entire process, not just a little, because otherwise you won't get rid of some of the old habits that have been plaguing the project. David
