On 19 Apr 2018, at 5:55 PM, David Zuelke <dzue...@salesforce.com> wrote:
> 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. Did you bring these regressions to our attention? Regressions get fix very quickly - there was an 18 month period between 2.4.20 and 2.4.29, what stopped it being possible to upgrade in that time? (As other people have said, there was no release between 2.4.16 and 2.4.18, 2.4.19 was replaced two weeks later, and there were no releases for you to have used between v2.4.29 and 2.4.33) > 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. Unfortunately this misses a fundamental reality of what the httpd project is - we are the foundation under many many other things, and when we jump from v2.4.x to v2.6.x, our complete ecosystem above us needs to be recompiled. This cannot be ignored, understated or taken lightly. > 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. Not only does it make sense, but it is vital we do so. We needed to get h2 support into the hands of end users - end users who were not going to recompile their entire web stack, who install software from distros who are not going to upgrade, who were deploying modules from vendors that were not going to recompile. Our average user will deploy whatever comes by default on their operating system, they’re not going to have a dedicated team that deploys a custom stack for their application. It is vital we respect the needs of these groups of users. > 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. I don’t see us having any of the problems you describe above to the extent where it would be a real problem. Part of the process of creating an odd numbered branch is to determine what from trunk gets carried over and what is not, this is all catered for in the process. > 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. Specifically what about the php release cycle are you referring to? I was burned badly a number of years ago by php config file formats being changed in point releases, have they improved their stability? > 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. There is a fundamental tension between two groups of people - people who want stability, and people who want features. I believe the httpd project has been very successful at trading off against these two, and other projects have a lot to learn from us. Regards, Graham —
smime.p7s
Description: S/MIME cryptographic signature
