Re: Status for 2.4.20
+1 Thanks! > Am 28.03.2016 um 17:06 schrieb William A Rowe Jr : > > @Everyone on this thread - keep it civil. > >> On Fri, Mar 25, 2016 at 10:13 PM, Noel Butler wrote: >>> On 25/03/2016 19:52, Graham Leggett wrote: >>> On 23 Mar 2016, at 1:58 PM, Noel Butler wrote: >>> as stated previously, this shit will happen when certain people push with a release often mentality AFAIK there is *ZERO* critical exploit bugs to be patched by any pending release, so lets get house in order S T A B L E , then worry about releases, jesus christ, we are not ubuntu or redhat with set programs to release every 3 or 6 months regardless if shit is ready or not….. >>> >>> It sounds like you’re making drama where there is none. >> >> sounds like you only look at this from one perspective, and thats not of the >> users, especially, the larger users. > > Precisely the point. If httpd were commercial software, there would only be > one perspective, that of the largest users with fairly static deployments that > demand very small deltas - those that ensure few if any regressions. Smaller > or more nimble users who need the most recent features are neglected in that > scenario. > > Instead httpd does not operate as commercial software, it is open source. > When it breaks, you get to keep (and patch) all the pieces. That's the origin > story of this software and our continued model for success. No amount of > pleas that "it shouldn't be that way" are going to change the mindset of the > project participants. Please remember you are a guest on this list. > > When we decided during 1.3.x that things were so shaky (third party module > recompilation was frequently necessary during the early 1.3.0-1.3.14 versions) > that we could do better for user communities. > > Therefore, when we released 2.0 as GA, we declared the ABI stable, and > proceeded on ABI and API breaking work on a 2.1-dev trunk branch. We all > agreed that 2.1 wouldn't be GA, but we would release 2.2.0 once we believed > that branch was ready to be ABI-stable. That model continues to this day, > breaking changes are on 2.5-dev in trunk, and we seek 100% compatibility > on the 2.4.x branch. There were contentious discussions that led us to this > model, but it was driven by competing interests by the developers of this > project, who are also users --- as opposed to external "demands". > > We will seek to continue to release early and often, and one of our current > faults is that we haven't been releasing 2.5-dev often enough to engage users > in the next release series, but pouring most of our energy into wedging these > changes back into the 2.4.x branch. But unlike commercial software and > many OSS projects, we don't declare 2.4.0 to be "feature complete", and > we continue to improve it in straightforward ways throughout the 2.4 lifetime. > > If you want to package a stable "product", you can follow the RedHat and > others' model. Just to take that single example, httpd 2.4.3 is the released > flavor by RedHat. They go to the extra effort to backport fixes-only and plan > to support that version for some 10 years or so. That is why many larger > users choose to stick with something like RHEL or CentOS or similar > distributions which are feature-frozen and much more stable than an active > product undergoing constant enhancement. > > Just to wrap up another tl;dr post... others offered you a different option, > skip those versions which are too "experimental" for your tastes, and wait > for bugs to shake out. We assert that 2.4.newest is the best available > version, but in such a large, modular and flexible project, it's impossible > to assure that a change set (release) will be an improvement for each and > every use case. > > Use the version that is most appropriate to your use case, and seek a > commercial product if you expect the sort of stasis that your protest > appears to seek. > >
Re: [PATCH] Add "FreeListen" to support IP_FREEBIND
On 03/28/2016 05:52 PM, Stefan Fritsch wrote: On Monday 07 March 2016 12:41:25, Jan Kaluža wrote: This is needed for httpd startup with systemd when one wants to use particular IP address to bind. There is no way how to start httpd after the IP address has been configured in systemd and according to systemd developers, the applications should become more robust to handle network changes like that. The full reasoning is explained here [1]. This is wrong. We really want to be able to check the configuration for correctness at startup. If you switch to using freebind by default, you loose that sanity check. And using freebind for all systemd users is basically the same as making it the default. I do not plan to enable that feature by default. I think 99% of the users use Listen without the particular public IP address, so there is no need to use it for them. Doesn't network-online.target do what you need? If no, why not? It does, but it's not what systemd authors describe as a best solution. Also, as Yann said, we might want to use that API even for different socket options in near future. You are right that from user perspective, it probably doesn't matter if the user enables network-online.target or adds freebind option to httpd - he has to change the configuration of the system anyway. I was just thinking that it would be nice to have a support for that even in httpd. I am not against the freebind feature as such, it's useful for failover solutions/VRRP/etc. But I am strictly against advertising this as a workaround for broken systemd design. We do not advertise it publicly as a workaround for systemd issues. I was using systemd in my email just to show the use-case I'm personally interested in. In the httpd documentation for this config option in my patch, there is no mention of systemd. I also personally think that systemd should handle this situation differently, but systemd developers think the opposite for a long time. I was discussing that with them and it's very unlikely that they would change something related to this problem. Regards, Jan Kaluza The patch needs latest APR-trunk currently, but it could be rewritten to set IP_FREEBIND directly instead of using APR API (We use that way for REUSEADDR socket option). Do you think FreeListen is good name for this feature, or would you name/implement it differently? [1] https://www.freedesktop.org/wiki/Software/systemd/NetworkTarget/
Re: [PATCH] Add "FreeListen" to support IP_FREEBIND
On Monday 07 March 2016 12:41:25, Jan Kaluža wrote: > This is needed for httpd startup with systemd when one wants to use > particular IP address to bind. There is no way how to start httpd > after the IP address has been configured in systemd and according > to systemd developers, the applications should become more robust > to handle network changes like that. The full reasoning is > explained here [1]. This is wrong. We really want to be able to check the configuration for correctness at startup. If you switch to using freebind by default, you loose that sanity check. And using freebind for all systemd users is basically the same as making it the default. Doesn't network-online.target do what you need? If no, why not? I am not against the freebind feature as such, it's useful for failover solutions/VRRP/etc. But I am strictly against advertising this as a workaround for broken systemd design. > > The patch needs latest APR-trunk currently, but it could be > rewritten to set IP_FREEBIND directly instead of using APR API (We > use that way for REUSEADDR socket option). > > Do you think FreeListen is good name for this feature, or would you > name/implement it differently? > > [1] https://www.freedesktop.org/wiki/Software/systemd/NetworkTarget/
Re: Status for 2.4.20
@Everyone on this thread - keep it civil. On Fri, Mar 25, 2016 at 10:13 PM, Noel Butler wrote: > On 25/03/2016 19:52, Graham Leggett wrote: > >> On 23 Mar 2016, at 1:58 PM, Noel Butler wrote: >> >> as stated previously, this shit will happen when certain people push with >>> a release often mentality >>> >>> AFAIK there is *ZERO* critical exploit bugs to be patched by any pending >>> release, so lets get house in order S T A B L E , then worry about >>> releases, jesus christ, we are not ubuntu or redhat with set programs to >>> release every 3 or 6 months regardless if shit is ready or not….. >>> >> >> It sounds like you’re making drama where there is none. >> > > sounds like you only look at this from one perspective, and thats not of > the users, especially, the larger users. Precisely the point. If httpd were commercial software, there would only be one perspective, that of the largest users with fairly static deployments that demand very small deltas - those that ensure few if any regressions. Smaller or more nimble users who need the most recent features are neglected in that scenario. Instead httpd does not operate as commercial software, it is open source. When it breaks, you get to keep (and patch) all the pieces. That's the origin story of this software and our continued model for success. No amount of pleas that "it shouldn't be that way" are going to change the mindset of the project participants. Please remember you are a guest on this list. When we decided during 1.3.x that things were so shaky (third party module recompilation was frequently necessary during the early 1.3.0-1.3.14 versions) that we could do better for user communities. Therefore, when we released 2.0 as GA, we declared the ABI stable, and proceeded on ABI and API breaking work on a 2.1-dev trunk branch. We all agreed that 2.1 wouldn't be GA, but we would release 2.2.0 once we believed that branch was ready to be ABI-stable. That model continues to this day, breaking changes are on 2.5-dev in trunk, and we seek 100% compatibility on the 2.4.x branch. There were contentious discussions that led us to this model, but it was driven by competing interests by the developers of this project, who are also users --- as opposed to external "demands". We will seek to continue to release early and often, and one of our current faults is that we haven't been releasing 2.5-dev often enough to engage users in the next release series, but pouring most of our energy into wedging these changes back into the 2.4.x branch. But unlike commercial software and many OSS projects, we don't declare 2.4.0 to be "feature complete", and we continue to improve it in straightforward ways throughout the 2.4 lifetime. If you want to package a stable "product", you can follow the RedHat and others' model. Just to take that single example, httpd 2.4.3 is the released flavor by RedHat. They go to the extra effort to backport fixes-only and plan to support that version for some 10 years or so. That is why many larger users choose to stick with something like RHEL or CentOS or similar distributions which are feature-frozen and much more stable than an active product undergoing constant enhancement. Just to wrap up another tl;dr post... others offered you a different option, skip those versions which are too "experimental" for your tastes, and wait for bugs to shake out. We assert that 2.4.newest is the best available version, but in such a large, modular and flexible project, it's impossible to assure that a change set (release) will be an improvement for each and every use case. Use the version that is most appropriate to your use case, and seek a commercial product if you expect the sort of stasis that your protest appears to seek.
