Re: Start using RCs (Was: Re: So... when should we do 2.4.34? [WAS: Re: Revisit Versioning? (Was: 2.4.3x regression w/SSL vhost configs)])

Let me counter with this... Rather than break the API every m.n release, what if we roll on to 2.6 with no ABI breakage, or resolve with impumity everything wrong in 3.0 with a firm commitment not to break it again till 4.0? This might be the root problem of our trying to !is versioning

Re: Start using RCs (Was: Re: So... when should we do 2.4.34? [WAS: Re: Revisit Versioning? (Was: 2.4.3x regression w/SSL vhost configs)])

I'm not sure where in the conversation to add this, but I do want to point out a mechanical concern. If we end up with API and feature freeze on branch 2.4, then we'd expect to roll 2.6. Soon enough, we'll hit a situation where 2.6 (as a release branch) can't get a feature or the next great

Re: So... when should we do 2.4.34? [WAS: Re: Revisit Versioning? (Was: 2.4.3x regression w/SSL vhost configs)]

I don't think Stefan is proposing that we mindlessly ship based on an arbitrary set of dates. That'd be too corporate :-) I think in the past you mentioned that we have had features/fixes/Good Stuff(tm) that was probably *ready*... just not yet released. I do recall a few times where there

Re: Start using RCs (Was: Re: So... when should we do 2.4.34? [WAS: Re: Revisit Versioning? (Was: 2.4.3x regression w/SSL vhost configs)])

I don't disagree with RC's entirely, or the mechanism you suggest, but that isn't what I read as proposed. Our issue is that every httpd must be distinguished, we won't ship four tarballs all claiming 2.4.34 (GA). Which one is the person complaining about? Are we back to SHA signature of the

Re: So... when should we do 2.4.34? [WAS: Re: Revisit Versioning? (Was: 2.4.3x regression w/SSL vhost configs)]

On 4/19/2018 7:55 AM, Eric Covener wrote: >> Again, this would be your burden and call until we have so much >> routine/automation that everyone can do it. So it needs to be your decision. > No offense intended here, but I did not really see as many html / > script / process updates as I had

Re: Revisit Versioning? (Was: 2.4.3x regression w/SSL vhost configs)

On Thu, Apr 19, 2018 at 11:07 PM, Mark Blackman wrote: > > >> On 19 Apr 2018, at 21:35, David Zuelke wrote: >> >> I'm not saying no directives should ever be added in point releases or >> anything, but the constant backporting of *features* to 2.4 has

Re: Start using RCs (Was: Re: So... when should we do 2.4.34? [WAS: Re: Revisit Versioning? (Was: 2.4.3x regression w/SSL vhost configs)])

The main difference is that you have a release branch in which fixes to bugs or regressions found during 2.4.x RCs can be made, while work on 2.4.(x+1) can continue in the main 2.4 branch. Another benefit is that people who do automated builds (e.g. me) can grep for "RC" in the version number and

Re: Revisit Versioning? (Was: 2.4.3x regression w/SSL vhost configs)

> On 19 Apr 2018, at 21:35, David Zuelke wrote: > > On Thu, Apr 19, 2018 at 8:25 PM, Jim Jagielski wrote: >> >> >>> On Apr 19, 2018, at 11:55 AM, David Zuelke wrote: >>> >>> >>> I hate to break this to you, and I do not

Re: Start using RCs (Was: Re: So... when should we do 2.4.34? [WAS: Re: Revisit Versioning? (Was: 2.4.3x regression w/SSL vhost configs)])

What possible improvement occurs if there is no branch discipline on 2.4.x development? We just echoed effectively your proposal, using numbers rather than RC designations, and still .33 has this host of issues. With no release since .29, the branch was in this continuous state of flux between

Re: Revisit Versioning? (Was: 2.4.3x regression w/SSL vhost configs)

On Thu, Apr 19, 2018 at 8:25 PM, Jim Jagielski wrote: > > >> On Apr 19, 2018, at 11:55 AM, David Zuelke 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

Re: Revisit Versioning? (Was: 2.4.3x regression w/SSL vhost configs)

All informative feedback is welcome on this /discussion/ thread. Jim, again, stop. Bullying list watchers with negative feedback into silence is a CoC violation. David, thank you for your detailed feedback. We are reading, whether the feedback is warmly received or not. On Thu, Apr 19, 2018

Re: Start using RCs (Was: Re: So... when should we do 2.4.34? [WAS: Re: Revisit Versioning? (Was: 2.4.3x regression w/SSL vhost configs)])

Yup, that's exactly it. Have a release branch, iterate there, and in the meantime, work in the version series branch can continue. That brings one huge benefit over the current model already: no freezes necessary, no potential additional breaks after a "burned" version. On Thu, Apr 19, 2018 at

Re: Start using RCs (Was: Re: So... when should we do 2.4.34? [WAS: Re: Revisit Versioning? (Was: 2.4.3x regression w/SSL vhost configs)])

Am 19.04.2018 um 17:37 schrieb Jim Jagielski: On Apr 19, 2018, at 11:26 AM, William A Rowe Jr wrote: On Thu, Apr 19, 2018 at 10:11 AM, Jim Jagielski wrote: With all this in mind, should we try to set things up so that the next release cycle uses the

Re: Revisit Versioning? (Was: 2.4.3x regression w/SSL vhost configs)

> On Apr 19, 2018, at 11:55 AM, David Zuelke 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. >

Re: 2.4.3x regression w/SSL vhost configs

Am 19.04.2018 um 17:55 schrieb David Zuelke: > 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

Re: Revisit Versioning? (Was: 2.4.3x regression w/SSL vhost configs)

On Wed, Apr 18, 2018 at 8:01 AM, Stefan Eissing wrote: > > >> Am 17.04.2018 um 19:18 schrieb William A Rowe Jr : >> >>> The architecture of v2.4 has been very stable, the need for breaking >>> changes has been largely non existent, and the focus

Re: Start using RCs (Was: Re: So... when should we do 2.4.34? [WAS: Re: Revisit Versioning? (Was: 2.4.3x regression w/SSL vhost configs)])

The idea is encouraging and fostering a broader test audience. > On Apr 19, 2018, at 11:44 AM, William A Rowe Jr wrote: > > Unless I misunderstand... > > 2.4.30-RC1 (rejected) > 2.4.30-RC2 (our .31, rejected) > 2.4.30-RC3 (our .32, rejected) > 2.4.30-RC4 -> 2.4.30 GA (our

Re: svn commit: r1829430 - /httpd/httpd/patches/2.4.x/core-check_errorlog_dir_syslog.patch

Luca - Here's the same thing standardizing on strn?cmp(). Not that you couldn't have done it yourself, but since I had it up, maybe this will save you 30 seconds. ;-) Index: server/core.c === --- server/core.c (revision

Re: svn commit: r1829430 - /httpd/httpd/patches/2.4.x/core-check_errorlog_dir_syslog.patch

Luca - Here's the same thing standardizing on strn?cmp(). Not that you couldn't have done it yourself, but since I had it up, maybe this will save you 30 seconds. ;-) Index: server/core.c === --- server/core.c (revision

Re: Start using RCs (Was: Re: So... when should we do 2.4.34? [WAS: Re: Revisit Versioning? (Was: 2.4.3x regression w/SSL vhost configs)])

Unless I misunderstand... 2.4.30-RC1 (rejected) 2.4.30-RC2 (our .31, rejected) 2.4.30-RC3 (our .32, rejected) 2.4.30-RC4 -> 2.4.30 GA (our 2.4.33 release) With all the associated changes in between, no actual change in branch management, scope, feature creep, etc? This sounds like dressing up

Re: Start using RCs (Was: Re: So... when should we do 2.4.34? [WAS: Re: Revisit Versioning? (Was: 2.4.3x regression w/SSL vhost configs)])

> On Apr 19, 2018, at 11:26 AM, William A Rowe Jr wrote: > > On Thu, Apr 19, 2018 at 10:11 AM, Jim Jagielski wrote: >> With all this in mind, should we try to set things up so that the >> next release cycle uses the concept of RCs? >> >> If so, and if

Re: Start using RCs (Was: Re: So... when should we do 2.4.34? [WAS: Re: Revisit Versioning? (Was: 2.4.3x regression w/SSL vhost configs)])

On Thu, Apr 19, 2018 at 10:11 AM, Jim Jagielski wrote: > With all this in mind, should we try to set things up so that the > next release cycle uses the concept of RCs? > > If so, and if people like, I can come up with a baseline > proposal on the process for us to debate and

Re: So... when should we do 2.4.34? [WAS: Re: Revisit Versioning? (Was: 2.4.3x regression w/SSL vhost configs)]

On Thu, Apr 19, 2018 at 10:08 AM, Jim Jagielski wrote: > >> On Apr 19, 2018, at 10:47 AM, William A Rowe Jr wrote: >> >> and BFDL/NIH-tier levels of "we don't do that, we do things this way... my >> way or the highway." > > That is not quite true nor

Start using RCs (Was: Re: So... when should we do 2.4.34? [WAS: Re: Revisit Versioning? (Was: 2.4.3x regression w/SSL vhost configs)])

With all this in mind, should we try to set things up so that the next release cycle uses the concept of RCs? If so, and if people like, I can come up with a baseline proposal on the process for us to debate and come to some consensus on.

Re: So... when should we do 2.4.34? [WAS: Re: Revisit Versioning? (Was: 2.4.3x regression w/SSL vhost configs)]

> On Apr 19, 2018, at 10:47 AM, William A Rowe Jr wrote: > > and BFDL/NIH-tier levels of "we don't do that, we do things this way... my > way or the highway." > That is not quite true nor fair. It does not take a BFDL/NIH-er, for example, to say "We don't release s/w

Re: So... when should we do 2.4.34? [WAS: Re: Revisit Versioning? (Was: 2.4.3x regression w/SSL vhost configs)]

On Thu, Apr 19, 2018, 09:32 Jim Jagielski wrote: > > > > On Apr 19, 2018, at 10:20 AM, Stefan Eissing < > stefan.eiss...@greenbytes.de> wrote: > > > > Frankly, I think the current state of things does not work well. It > seems folly to say we should change nothing, only have

Re: So... when should we do 2.4.34? [WAS: Re: Revisit Versioning? (Was: 2.4.3x regression w/SSL vhost configs)]

> On Apr 19, 2018, at 10:20 AM, Stefan Eissing > wrote: > > Frankly, I think the current state of things does not work well. It seems > folly to say we should change nothing, only have more stable releases. No one is saying we change *nothing*. There just seems

Re: Expanding httpd adoption internationally - POC

On Thu, Apr 19, 2018 at 10:24 AM, Eric Covener wrote: > On Thu, Apr 19, 2018 at 9:38 AM, Eric Covener wrote: >>> If using gettext, there are some tools to check for that. >> >> Would be nice to put some feelers out to $bigcos to make sure we >> choose a

Re: Expanding httpd adoption internationally - POC

On Thu, Apr 19, 2018 at 9:38 AM, Eric Covener wrote: >> If using gettext, there are some tools to check for that. > > Would be nice to put some feelers out to $bigcos to make sure we > choose a format they'd accomoddate [if they were otherwise willing to > donate a one-time

Re: "Most Popular Web Server?"

On 04/19/2018 05:43 AM, Nick Kew wrote: If you want to get writing at a serious level, that’ll be great! I might even contribute if you can get some momentum going, but I’d never attempt to take a lead, not least because potential conflict-of-interest with my publisher’s copyright.

Re: cygwin-oriented scripts that grab deps, cmake, etc for win build?

On Thu, Apr 19, 2018 at 9:38 AM, William A Rowe Jr wrote: > On Thu, Apr 19, 2018 at 7:52 AM, Eric Covener wrote: >> Hi All, sorry for the lazyness, but does anyone have even a partial >> set of scripts to drive the windows cmake build including obtaining

Re: AW: So... when should we do 2.4.34? [WAS: Re: Revisit Versioning? (Was: 2.4.3x regression w/SSL vhost configs)]

Frankly, I think the current state of things does not work well. It seems folly to say we should change nothing, only have more stable releases. Our current approach gave us around 6 months of „ship when it‘s ready“ and the quality is not what we want - as expressed by Jim, Bill and others.

Re: So... when should we do 2.4.34? [WAS: Re: Revisit Versioning? (Was: 2.4.3x regression w/SSL vhost configs)]

2018-04-19 15:40 GMT+02:00 Eric Covener : > On Thu, Apr 19, 2018 at 9:31 AM, Jim Jagielski wrote: > > I agree a case could be made for considering adding an RC stage > > to our release process... it would require some additional tooling > > and some sort of

AW: So... when should we do 2.4.34? [WAS: Re: Revisit Versioning? (Was: 2.4.3x regression w/SSL vhost configs)]

I am also more in the "ship when it is ready", then "ship when it is time" boat. We probably could have some automated "nightlyies" which are not releases in the ASF sense (as release requires voting), but only some sort of convenience transformation of an svn export / co that creates a tar

Re: So... when should we do 2.4.34? [WAS: Re: Revisit Versioning? (Was: 2.4.3x regression w/SSL vhost configs)]

On Thu, Apr 19, 2018 at 9:31 AM, Jim Jagielski wrote: > I agree a case could be made for considering adding an RC stage > to our release process... it would require some additional tooling > and some sort of additions to ap_release.h but nothing insurmountable. > > That might be

Re: cygwin-oriented scripts that grab deps, cmake, etc for win build?

On Thu, Apr 19, 2018 at 7:52 AM, Eric Covener wrote: > Hi All, sorry for the lazyness, but does anyone have even a partial > set of scripts to drive the windows cmake build including obtaining > common prereqs? > > I believe I have seen 1 or two batch oriented ones that I'd

Re: Expanding httpd adoption internationally - POC

> If using gettext, there are some tools to check for that. Would be nice to put some feelers out to $bigcos to make sure we choose a format they'd accomoddate [if they were otherwise willing to donate a one-time translation] -- Eric Covener cove...@gmail.com

Re: So... when should we do 2.4.34? [WAS: Re: Revisit Versioning? (Was: 2.4.3x regression w/SSL vhost configs)]

I agree a case could be made for considering adding an RC stage to our release process... it would require some additional tooling and some sort of additions to ap_release.h but nothing insurmountable. That might be a nice small-and-easily-reversable step to address some of the issues that we've

Re: So... when should we do 2.4.34? [WAS: Re: Revisit Versioning? (Was: 2.4.3x regression w/SSL vhost configs)]

++1 The current versioning and times are fine for me. Only the vote time is too short. At Apachelounge I have once in a while RC’s from branches before voting, so the community had more time to test. Issues are then earlier discovered. Distributors are free to have a RC any time when they

Re: So... when should we do 2.4.34? [WAS: Re: Revisit Versioning? (Was: 2.4.3x regression w/SSL vhost configs)]

One of the great things about working on open source is that one is NOT burdened by schedules. That releases are done "when ready" not when some artificial schedule or some calendar date demands. Changing this mindset on httpd would be an extremely major change, IMO, from what's been at its heart

Re: "Most Popular Web Server?"

> On Apr 19, 2018, at 6:29 AM, Dirk-Willem van Gulik > wrote: > > > Large crude oil tankers and formula 1 racing cars are both things that can go > from A to B. Yet they have different qualities. > > Perhaps we need to emphasise this a bit more - that there is room

Re: [Bug 62308] New: Apache crashes after graceful restart with AH02599: slotmem (failed size check)

Bill, you continue to ignore the fact that I use the term "*we*" "We" is *inclusive*. Again, in your continued efforts to win points and cast aspersions, you completely miss the point. > On Apr 18, 2018, at 10:26 PM, William A Rowe Jr wrote: > > Does the root of this

Re: So... when should we do 2.4.34? [WAS: Re: Revisit Versioning? (Was: 2.4.3x regression w/SSL vhost configs)]

> Again, this would be your burden and call until we have so much > routine/automation that everyone can do it. So it needs to be your decision. No offense intended here, but I did not really see as many html / script / process updates as I had expected. I was hoping the new eyes would get some

Re: So... when should we do 2.4.34? [WAS: Re: Revisit Versioning? (Was: 2.4.3x regression w/SSL vhost configs)]

On Wed, Apr 18, 2018 at 6:43 PM, Daniel Ruggeri wrote: > On 4/18/2018 10:58 AM, William A Rowe Jr wrote: >>> The release cycle is hours, to the benefit of all interested. Be it a >>> blocking bug fixed or a nice feature implemented. These are mostly people >>> who do it

cygwin-oriented scripts that grab deps, cmake, etc for win build?

Hi All, sorry for the lazyness, but does anyone have even a partial set of scripts to drive the windows cmake build including obtaining common prereqs? I believe I have seen 1 or two batch oriented ones that I'd just as well avoid 'cept for hints about how to do it in bash/cygwin. Thanks! --

Re: "Most Popular Web Server?"

++1 > On Apr 19, 2018, at 6:09 AM, Graham Leggett wrote: > > On 18 Apr 2018, at 10:46 PM, Mark Blackman wrote: > >> Is most popular the right thing to aim for? I would advise continuing to >> trade on Apache’s current strengths (versatility and

Re: Revisit Versioning? (Was: 2.4.3x regression w/SSL vhost configs)

On 19 Apr 2018, at 11:57 AM, Joe Orton wrote: > Feel like I should drop 2c in here... > > I'd be VERY happy to see more frequent "major" version bumps, i.e. > 2.4->2.6->2.8 or whatever which break backwards compat/ABI. We have the > chance to break compat every ~6 months

Re: "Most Popular Web Server?"

On 18 Apr 2018, at 8:32 PM, William A Rowe Jr wrote: >> You seem to be making a mountain out of a molehill [...] > > > Both statements attack not the technical question, but the questioner. > Please mind your framing. The expression “making a mountain out of a molehill”

Re: "Most Popular Web Server?"

On 19 Apr 2018, at 12:09, Graham Leggett wrote: > On 18 Apr 2018, at 10:46 PM, Mark Blackman wrote: > >> Is most popular the right thing to aim for? I would advise continuing to >> trade on Apache’s current strengths (versatility and documentation for me

Re: "Most Popular Web Server?"

On 18 Apr 2018, at 10:46 PM, Mark Blackman wrote: > Is most popular the right thing to aim for? I would advise continuing to > trade on Apache’s current strengths (versatility and documentation for me and > relative stability) and let the chips fall where they may. It’s an

Re: Revisit Versioning? (Was: 2.4.3x regression w/SSL vhost configs)

Feel like I should drop 2c in here... I'd be VERY happy to see more frequent "major" version bumps, i.e. 2.4->2.6->2.8 or whatever which break backwards compat/ABI. We have the chance to break compat every ~6 months in Fedora so it's no problem getting new code into the hands of users. I've

Re: "Most Popular Web Server?"

> On 19 Apr 2018, at 10:14, Luca Toscano wrote: > > Hi Nick, [chop] Thanks. Good reply. Your suggestions make a lot of sense to me: I just wouldn’t have put them in the context of marketing or evangelism. Trouble is, it’s relatively few of us who ever get inspired

Re: 2.4.3x regression w/SSL vhost configs

Thanks to everyone who followed through :) For completion, I pushed this to trunk in r1829513 though arguably we could/should accept some behavioural change here in 2.5. No strong opinion on this really. 2.4 backport also proposed. It bugs me to be left with the "surprising" behaviour of

Re: "Most Popular Web Server?"

Hi Nick, 2018-04-19 10:33 GMT+02:00 Nick Kew : > > > On 18 Apr 2018, at 20:00, Luca Toscano wrote: > > > > Before joining the httpd project as contributor I struggled to find good > technical sources about how the httpd internals work, > > Likewise.

Re: "Most Popular Web Server?"

> On 18 Apr 2018, at 20:00, Luca Toscano wrote: > > Before joining the httpd project as contributor I struggled to find good > technical sources about how the httpd internals work, Likewise. That’s kind-of what motivated me to start writing about it. But that’s not

AW: "Most Popular Web Server?"

> -Ursprüngliche Nachricht- > Von: Daniel Ruggeri [mailto:drugg...@primary.net] > Gesendet: Donnerstag, 19. April 2018 02:22 > An: dev@httpd.apache.org > Betreff: Re: "Most Popular Web Server?" > > On 4/18/2018 11:46 AM, Jim Jagielski wrote: > > > Personally, I'd like to see the the

AW: /scheme/i sensitivity? (was: svn commit: r1829430 - /httpd/httpd/patches/2.4.x/core-check_errorlog_dir_syslog.patch)

> -Ursprüngliche Nachricht- > Von: William A Rowe Jr [mailto:wr...@rowe-clan.net] > Gesendet: Mittwoch, 18. April 2018 18:49 > An: httpd > Betreff: /scheme/i sensitivity? (was: svn commit: r1829430 - >