Re: [VOTE] Allow for defect fix releases at httpd
> On 2 May 2018, at 15:45, Micha Lenk wrote: > > Hi Graham, > > On 05/01/2018 04:33 PM, Graham Leggett wrote: >> What has been missing is input from the major distributors of our >> software (Fedora, Ubuntu, Redhat, Debian, Apple, Windows, Linux from >> Scratch, etc), who I believe are probably going “httpd is a mature >> project, we have nothing to worry about”. I would recommend against >> making changes to our approach without soliciting the views of these >> people and making sure they’re all catered for. > Why would you make a proposed change dependent on the (almost necessarily > contradicting) views of external entities? Is the feedback from the major > distributors through existing channels really so bad that the httpd project > can't get to an opinion of what it would like to accomplish on its own? What > exactly are you afraid of? +1 to Jim’s reply to that (insofar as it addresses your point). I’d also add: this mailinglist is open to our downstream packagers. Some of them contribute actively, and one would hope they all at least keep an eye on this list and would speak up if a proposal seemed likely to cause them real difficulties. So open discussion here *should* provide a reasonable level of engagement with our distributors. — Nick Kew
Re: [VOTE] Allow for defect fix releases at httpd
> On May 2, 2018, at 10:45 AM, Micha Lenk wrote: > > Hi Graham, > > On 05/01/2018 04:33 PM, Graham Leggett wrote: >> What has been missing is input from the major distributors of our >> software (Fedora, Ubuntu, Redhat, Debian, Apple, Windows, Linux from >> Scratch, etc), who I believe are probably going “httpd is a mature >> project, we have nothing to worry about”. I would recommend against >> making changes to our approach without soliciting the views of these >> people and making sure they’re all catered for. > Why would you make a proposed change dependent on the (almost necessarily > contradicting) views of external entities? Is the feedback from the major > distributors through existing channels really so bad that the httpd project > can't get to an opinion of what it would like to accomplish on its own? What > exactly are you afraid of? > Due to the modular aspect of httpd, we are lucky to have an extremely large, vibrant and diverse eco-system of module authors. Some are companies that provide functionality via binary modules, others are single-author GitHub authors. A change on versioning and what versioning means and guarantees related to versioning affects this extremely large community. There is also the ISV and commercial *providers* of httpd to be considered as well, and how these changes would affect them. With all that in mind, you can't just "willy-nilly" decide to change things without knowledge of how such changes will affect the eco- system as well as without a really solid rationale for said change. I don't consider "I can point out a handful of projects that do it different than httpd" as a solid rationale.
Re: [VOTE] Allow for defect fix releases at httpd
Hi Graham, On 05/01/2018 04:33 PM, Graham Leggett wrote: What has been missing is input from the major distributors of our software (Fedora, Ubuntu, Redhat, Debian, Apple, Windows, Linux from Scratch, etc), who I believe are probably going “httpd is a mature project, we have nothing to worry about”. I would recommend against making changes to our approach without soliciting the views of these people and making sure they’re all catered for. Why would you make a proposed change dependent on the (almost necessarily contradicting) views of external entities? Is the feedback from the major distributors through existing channels really so bad that the httpd project can't get to an opinion of what it would like to accomplish on its own? What exactly are you afraid of? Regards, Micha
Re: time for 2.4.34?
Yes, for sure :) > On May 1, 2018, at 9:32 PM, Alain Toussaint wrote: > > I promised a patch for BLFS layout and haven't delivered yet. Will the > release happen after > Thursday? (I'll take Thursday to deliver the layout patch). > > Alain
Re: time for 2.4.34?
On Tue, May 1, 2018 at 11:15 PM, Jim Jagielski wrote: > Considering that we have some regressions in .33 which > will soon be fixed (these are the 2 noted ShowStoppers) The fix for PR 62308 is being tested and we should be good soon, I think. I don't think PR 62277 is a regression/showstopper, the OP reports an issue on slotmems after an upgrade from 2.2 to 2.4 (slotmems didn't exist in 2.2, and the mod_proxy_lb quite changed in between). Also, it looks more like an IPC-SysV "limitation" (on some Solaris version?) than a bug in our code, maybe should we consider a move to POSIX sems by default in trunk/2.next? By the way, I modified the tool (attached in bz) to show what I suspect are spurious collisions in ftok()+semget() with the OP's balancers' names, but he switched to POSIX sems so I'm not sure he will test any further. Possibly Rainer could try to run it on his Solaris(es) to confirm or not (no specific version mentioned in bz...). > as well as a limited number of "other" changes to the > codebase, maybe now is a Good Time to consider a 2.4.34...? +1, once these are addressed. > > I offer to RM using Daniel's updated release scripts so > we can get a different set of eyes using the scripts. Thanks! Regards, Yann.
Re: time for 2.4.34?
On Tue, May 01, 2018 at 05:15:54PM -0400, Jim Jagielski wrote: > Considering that we have some regressions in .33 which > will soon be fixed (these are the 2 noted ShowStoppers) > as well as a limited number of "other" changes to the > codebase, maybe now is a Good Time to consider a 2.4.34...? > > I offer to RM using Daniel's updated release scripts so > we can get a different set of eyes using the scripts. Thanks Jim that sounds good. FYI on the mod_ssl vhost fix, Fedora users are giving +ve feedback from testing that patch - https://bugzilla.redhat.com/show_bug.cgi?id=1564537 Regards, Joe
Re: time for 2.4.34?
+1. Some h2 issues accumulated, just got confirmation on the keepalive fix and will propose for backport today. Nothing else in the pipe from me. > Am 01.05.2018 um 23:15 schrieb Jim Jagielski : > > Considering that we have some regressions in .33 which > will soon be fixed (these are the 2 noted ShowStoppers) > as well as a limited number of "other" changes to the > codebase, maybe now is a Good Time to consider a 2.4.34...? > > I offer to RM using Daniel's updated release scripts so > we can get a different set of eyes using the scripts.
