Re: Versioning, Release Management, Stabilization, etc ... Subversion style

A useful, well-documented process of a fellow Apache community ... a process that has worked steadily and produced (your words) "outstanding stability, backwards compat, and steadily add new features, big and small". We're talking process, not the merits of software package that uses it (and this

Re: Versioning, Release Management, Stabilization, etc ... Subversion style

(as a completely external voice, user, packager, architect of systems big and small) - would it not make sense to model the workflow of a project that has a more positive feature _and_ stability profile? With all due respect, Subversion is an old project, offering little new, with a dwindling

Re: svn commit: r1829659 - in /httpd/httpd/trunk: include/ap_mmn.h include/http_protocol.h server/protocol.c

On 04/20/2018 04:30 PM, yla...@apache.org wrote: > Author: ylavic > Date: Fri Apr 20 14:30:19 2018 > New Revision: 1829659 > > URL: http://svn.apache.org/viewvc?rev=1829659=rev > Log: > http: add ap_fgetline() and AP_GETLINE_NONBLOCK flag. > > It allows to read a line directly from an input

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

On Fri, Apr 20, 2018, 10:37 Paul Querna wrote: > > I believe having more minor releases and less major backports to patch > releases is a good thing. > > I believe we gave the even/odd, 2.1/2.3 "unstable", thing a long run. > About 15 years of it. > > Since then the wider open

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

> On 20 Apr 2018, at 09:52, Luca Toscano wrote: > 2018-04-20 16:27 GMT+02:00 Jim Riggs : > > On 20 Apr 2018, at 08:53, Jim Jagielski wrote: > > > > Sorry for coming in late, but what is the exact issue we are trying to > > solve again?

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

I believe having more minor releases and less major backports to patch releases is a good thing. I believe we gave the even/odd, 2.1/2.3 "unstable", thing a long run. About 15 years of it. Since then the wider open source world has gone to a more canonical semver. I think we should generally

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

2018-04-20 16:27 GMT+02:00 Jim Riggs : > > On 20 Apr 2018, at 08:53, Jim Jagielski wrote: > > > > Sorry for coming in late, but what is the exact issue we are trying to > solve again? My understanding was that if someone wanted something like > > > >

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

> On 20 Apr 2018, at 08:53, Jim Jagielski wrote: > > Sorry for coming in late, but what is the exact issue we are trying to solve > again? My understanding was that if someone wanted something like > > ErrorLog "syslog-httpd.log" > > that the current implementation

Re: Versioning, Release Management, Stabilization, etc ... Subversion style

Great info! Thanks! > On Apr 20, 2018, at 9:52 AM, Greg Stein wrote: > > Hi all, > > I've been kind of watching the thrashing around on several threads now about > problems and fixes to how the HTTPD project manages its process around > releases. I thought it might be a

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

Sorry for coming in late, but what is the exact issue we are trying to solve again? My understanding was that if someone wanted something like ErrorLog "syslog-httpd.log" that the current implementation would, incorrectly, send the log data to syslogd. Is that right?

Versioning, Release Management, Stabilization, etc ... Subversion style

Hi all, I've been kind of watching the thrashing around on several threads now about problems and fixes to how the HTTPD project manages its process around releases. I thought it might be a good idea to suggest a tried-and-true alternative defined by the Apache Subversion project, and documented

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

> On Apr 18, 2018, at 11:15 AM, William A Rowe Jr wrote: > > > Shouldn't we normalize the use of strcmp instead of strcasecmp? > In any case it must be entirely normalized to one or the other. > > Linux is a case-sensitive OS in the first place, and if configured > with

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

> On 20 Apr 2018, at 01:42, Luca Toscano wrote: > 2018-04-19 17:49 GMT+02:00 Jim Riggs : > 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

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 20, 2018, at 8:28 AM, Micha Lenk wrote: > > Hi Jim, > > On 04/20/2018 01:46 PM, Jim Jagielski wrote: >> Where numbers and versioning DOES matter is how it affects >> distributors and vendors of httpd and the entire module eco-system. > No, it doesn't. There are way

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)])

Hi Jim, On 04/20/2018 01:46 PM, Jim Jagielski wrote: Where numbers and versioning DOES matter is how it affects distributors and vendors of httpd and the entire module eco-system. No, it doesn't. There are way too many variants of versioning schemes out there in use by so many OSS projects

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

> On Apr 20, 2018, at 8:04 AM, Micha Lenk wrote: > > In my role as Debian Developer maintaining the Debian packages of other OSS > projects, and also in my role of maintaining a commercial reverse proxy > product based on Apache httpd during my day job, I value the ability

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

Hi all, On 04/20/2018 01:34 PM, Jim Jagielski wrote: But why does it matter that h2 was added in 2.4.x instead of a 2.6.0? Because it sets a bad precedence (or even continues to do so)? Every new feature must bump the minor? Even if there is no corresponding ABI issue? Why not? In my

Re: "Most Popular Web Server?"

> On Apr 20, 2018, at 7:19 AM, Rich Bowen wrote: > > Perhaps this is something we can try for a few months and see what kind of > schedule we're able to hit. Luca, is this something you'd like to tackle with > me? I'd like to help too... if possible.

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

Am 20.04.2018 um 11:39 schrieb Eric Covener: On Fri, Apr 20, 2018 at 3:15 AM, Rainer Jung wrote: Do we need a quick APR 1.6.4 to pick up r1819938? From CHANGES: *) poll, port: re-add the wakeup pipe to the pollset after it triggered. Not doing this occasionally

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 20, 2018, at 1:08 AM, William A Rowe Jr wrote: > > 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

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

> On Apr 19, 2018, at 4:35 PM, David Zuelke wrote: > > > Of course, but that's exactly my point. It was introduced not in > 2.4.0, but in 2.4.17. Five "H2…" config directives are available in > 2.4.18+ only, one in 2.4.19+, and three in 2.4.24+. > But why does it

Re: "Most Popular Web Server?"

On Wed, Apr 18, 2018, 12:46 Jim Jagielski wrote: > > > Personally, I'd like to see the the PMC take a more active and > direct role in addressing #1, maybe w/ monthly blog posts > coordinated w/ Sally. It would also be cool to reboot Apache Week > (I know it was an external,

Re: svn commit: r1829642 - in /httpd/httpd/trunk: CHANGES modules/http/http_filters.c

On Fri, Apr 20, 2018 at 7:07 AM, Eric Covener wrote: > I don't remember this at all but: > > http://svn.apache.org/viewvc?rev=1031564=rev This seems like a step 0.5 of document the status quo but I cannot find any thing that precedes or follows it :/

Re: svn commit: r1829642 - in /httpd/httpd/trunk: CHANGES modules/http/http_filters.c

I don't remember this at all but: http://svn.apache.org/viewvc?rev=1031564=rev On Fri, Apr 20, 2018 at 7:06 AM, Eric Covener wrote: > On Fri, Apr 20, 2018 at 6:54 AM, Yann Ylavic wrote: >> On Fri, Apr 20, 2018 at 11:50 AM, Eric Covener

Re: svn commit: r1829642 - in /httpd/httpd/trunk: CHANGES modules/http/http_filters.c

On Fri, Apr 20, 2018 at 6:54 AM, Yann Ylavic wrote: > On Fri, Apr 20, 2018 at 11:50 AM, Eric Covener wrote: >> >> Not sure about change but re: comment >> >> Are those comparable? The new proxy parm ResponseFieldSize is like >> LimitRequestFieldSize not

Re: svn commit: r1829642 - in /httpd/httpd/trunk: CHANGES modules/http/http_filters.c

On Fri, Apr 20, 2018 at 11:50 AM, Eric Covener wrote: > > Not sure about change but re: comment > > Are those comparable? The new proxy parm ResponseFieldSize is like > LimitRequestFieldSize not LimitRequestBody? Yes indeed, I made a confusion here (comment restored in

Re: svn commit: r1829642 - in /httpd/httpd/trunk: CHANGES modules/http/http_filters.c

On Fri, Apr 20, 2018 at 5:46 AM, wrote: > Author: ylavic > Date: Fri Apr 20 09:46:51 2018 > New Revision: 1829642 > > URL: http://svn.apache.org/viewvc?rev=1829642=rev > Log: > http: LimitRequestBody applies to proxied requests. > > If f->r->proxyreq is PROXYREQ_PROXY or

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

On Fri, Apr 20, 2018 at 3:15 AM, Rainer Jung wrote: > Do we need a quick APR 1.6.4 to pick up r1819938? From CHANGES: > > *) poll, port: re-add the wakeup pipe to the pollset after it triggered. >Not doing this occasionally lead to httpd event MPM processes hanging >

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

On Fri, Apr 20, 2018 at 2:36 AM, Rainer Jung wrote: > >> The necessity/evaluation of the dependency belongs >> here... we once could compile httpd 2.4 against APR 1.4 family and had >> agreement that this would continue through the lifecycle, but I seriously >> doubt that

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 20 Apr 2018, at 01:39, Daniel Ruggeri wrote: > > 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

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 04/19/2018 09:19 PM, Rainer Jung wrote: > 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

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

Am 20.04.2018 um 09:22 schrieb William A Rowe Jr: On Fri, Apr 20, 2018 at 2:15 AM, Rainer Jung wrote: Do we need a quick APR 1.6.4 to pick up r1819938? From CHANGES: *) poll, port: re-add the wakeup pipe to the pollset after it triggered. Not doing this

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

On Fri, Apr 20, 2018 at 2:15 AM, Rainer Jung wrote: > Do we need a quick APR 1.6.4 to pick up r1819938? From CHANGES: > > *) poll, port: re-add the wakeup pipe to the pollset after it triggered. >Not doing this occasionally lead to httpd event MPM processes hanging >

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

Do we need a quick APR 1.6.4 to pick up r1819938? From CHANGES: *) poll, port: re-add the wakeup pipe to the pollset after it triggered. Not doing this occasionally lead to httpd event MPM processes hanging during process shutdown. PR 61786. [Yann Ylavic] From the commit log:

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

2018-04-19 17:49 GMT+02:00 Jim Riggs : > 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. ;-) > > Thanks a lot! I added your last suggestions to r1829626 and