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

[Greg Stein]

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 isn't the place to argue svn's merits).

Frankly, HTTPD does not have a well-documented process to balance
stability, compatibility, and progress. Leveraging svn's process could be
helpful, with some tuning specific to the httpd community.

Cheers,
-g


On Fri, Apr 20, 2018 at 4:18 PM, Martin Langhoff 
wrote:

> (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 userbase. New adoptions of subversion are not something
> you hear about.
>
> I would instead look at git -- not because it's an SCM, but because it's a
> smaller, simpler, and less "personality-driven" version of the Linux kernel
> workflow. Or PostgreSQL, which is evolving towards something similar but
> even less personality-driven.
>
> Both git and Pg offer really outstanding stability, backwards compat, and
> steadily add new features, big and small. Every time I look I am pleasantly
> surprised of the new bits added.
>
> with high regards, and respect,
>
>
>
> martin
>
> On Fri, Apr 20, 2018 at 10:05 AM, Jim Jagielski  wrote:
>
>> 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 good idea to suggest a
>> tried-and-true alternative defined by the Apache Subversion project, and
>> documented extensively at [1].
>>
>> That is a lot to wade through, and parts just don't apply ... but even
>> reading some of that could be helpful when read as a comparative point to
>> how HTTPD historically does its T and branch/release management. That
>> Subversion "manual" on releases is very stable, and what we've been
>> doing/developed during our 18 years, especially with the project's
>> understanding of version control, and svn specifically :-)
>>
>> Read the "Stabilizing and maintaining releases" section at a minimum,
>> please. That is kind of core to some of the issues on the mailing list
>> recently, and it describes how Subversion does things.
>>
>> I don't want to write a tome, but to begin a discussion to adopt that
>> documented approach with tweaks for httpd. So to write a shorter note, I'd
>> basically summarize as:
>>
>> * all development occurs on trunk
>> * release branches are made off trunk for each MINOR release (see the
>> 1.$N.x branches at [2])
>> * stabilization occurs on release branches by only cherry-picking
>> existing work/changes off of trunk
>> * when a release branch is made, trunk's version is bumped (ie. say trunk
>> is 2.5, the 2.6.x branch is made, then trunk becomes 2.7)
>> * IMO, don't bother making 2.7.x releases; just use the number to
>> determine if somebody grabbed a snapshot of trunk (svn happens to be
>> 1.11.0-dev in trunk, and will become 1.12.0-dev once the 1.11.x branch is
>> made; the svn project looks for a reported version of "-dev" for such
>> snapshot behavior) ... if you're going to think about a 2.7.x "test"
>> release, then just make it 2.8.x instead and label the feature experimental.
>> * trunk is always stable and passes buildbot tests
>> * version numbers are cheap, feel free to burn them (see our CHANGES[3]
>> where many specific numbers are recorded as "Not released")
>> * Subversion has its own compatibility declarations defined around
>> major/minor; I'd suggest skip that and stick to the existing HTTPD "MMN"
>> system
>>
>> I think that is most of the highlights. Again: I'd suggest reading the
>> section on Stabilization, and maybe "Creating and maintaining release
>> branches" section. The whole page for extra credit :-)
>>
>> Cheers,
>> -g
>>
>> [1] http://subversion.apache.org/docs/community-guide/releasing.html
>> [2] http://svn.apache.org/repos/asf/subversion/branches/
>> [3] http://svn.apache.org/repos/asf/subversion/trunk/CHANGES
>>
>>
>>
>
>
> --
>  martin.langh...@gmail.com
>  - ask interesting questions  ~  http://linkedin.com/in/martinlanghoff
>  - don't be distracted~  http://github.com/martin-langhoff
>by shiny stuff
>

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

[Martin Langhoff]

(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 userbase. New adoptions of subversion are not something
you hear about.

I would instead look at git -- not because it's an SCM, but because it's a
smaller, simpler, and less "personality-driven" version of the Linux kernel
workflow. Or PostgreSQL, which is evolving towards something similar but
even less personality-driven.

Both git and Pg offer really outstanding stability, backwards compat, and
steadily add new features, big and small. Every time I look I am pleasantly
surprised of the new bits added.

with high regards, and respect,



martin

On Fri, Apr 20, 2018 at 10:05 AM, Jim Jagielski  wrote:

> 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 good idea to suggest a
> tried-and-true alternative defined by the Apache Subversion project, and
> documented extensively at [1].
>
> That is a lot to wade through, and parts just don't apply ... but even
> reading some of that could be helpful when read as a comparative point to
> how HTTPD historically does its T and branch/release management. That
> Subversion "manual" on releases is very stable, and what we've been
> doing/developed during our 18 years, especially with the project's
> understanding of version control, and svn specifically :-)
>
> Read the "Stabilizing and maintaining releases" section at a minimum,
> please. That is kind of core to some of the issues on the mailing list
> recently, and it describes how Subversion does things.
>
> I don't want to write a tome, but to begin a discussion to adopt that
> documented approach with tweaks for httpd. So to write a shorter note, I'd
> basically summarize as:
>
> * all development occurs on trunk
> * release branches are made off trunk for each MINOR release (see the
> 1.$N.x branches at [2])
> * stabilization occurs on release branches by only cherry-picking existing
> work/changes off of trunk
> * when a release branch is made, trunk's version is bumped (ie. say trunk
> is 2.5, the 2.6.x branch is made, then trunk becomes 2.7)
> * IMO, don't bother making 2.7.x releases; just use the number to
> determine if somebody grabbed a snapshot of trunk (svn happens to be
> 1.11.0-dev in trunk, and will become 1.12.0-dev once the 1.11.x branch is
> made; the svn project looks for a reported version of "-dev" for such
> snapshot behavior) ... if you're going to think about a 2.7.x "test"
> release, then just make it 2.8.x instead and label the feature experimental.
> * trunk is always stable and passes buildbot tests
> * version numbers are cheap, feel free to burn them (see our CHANGES[3]
> where many specific numbers are recorded as "Not released")
> * Subversion has its own compatibility declarations defined around
> major/minor; I'd suggest skip that and stick to the existing HTTPD "MMN"
> system
>
> I think that is most of the highlights. Again: I'd suggest reading the
> section on Stabilization, and maybe "Creating and maintaining release
> branches" section. The whole page for extra credit :-)
>
> Cheers,
> -g
>
> [1] http://subversion.apache.org/docs/community-guide/releasing.html
> [2] http://svn.apache.org/repos/asf/subversion/branches/
> [3] http://svn.apache.org/repos/asf/subversion/trunk/CHANGES
>
>
>


-- 
 martin.langh...@gmail.com
 - ask interesting questions  ~  http://linkedin.com/in/martinlanghoff
 - don't be distracted~  http://github.com/martin-langhoff
   by shiny stuff

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

[Ruediger Pluem]

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 filter, in blocking mode
> or not. Since no request_rec is needed, a pool may be given.
> 
> Existing ap_[r]getline() function are now based off ap_fgetline() by calling:
> ap_fgetline(s, n, read, r->proto_input_filters, flags, bb, r->pool);
> 
> Will follow up with a new ap_get_mime_headers_*() flavor which can be used by
> any filter that needs non-blocking and not necessarily has a request_rec (e.g.
> ap_http_filter() to read proxied response trailers).
> 
> 
> Modified:
> httpd/httpd/trunk/include/ap_mmn.h
> httpd/httpd/trunk/include/http_protocol.h
> httpd/httpd/trunk/server/protocol.c
> 

> Modified: httpd/httpd/trunk/server/protocol.c
> URL: 
> http://svn.apache.org/viewvc/httpd/httpd/trunk/server/protocol.c?rev=1829659=1829658=1829659=diff
> ==
> --- httpd/httpd/trunk/server/protocol.c (original)
> +++ httpd/httpd/trunk/server/protocol.c Fri Apr 20 14:30:19 2018

> @@ -517,10 +522,31 @@ cleanup:
>  return rv;
>  }
>  
> +AP_DECLARE(apr_status_t) ap_fgetline(char **s, apr_size_t n,
> + apr_size_t *read, ap_filter_t *f,
> + int flags, apr_bucket_brigade *bb,
> + apr_pool_t *p)
> +{
> +return ap_fgetline_impl(s, n, read, f, flags, bb, p);
> +}
> +
> +/* Same as ap_fgetline(), working on r's pool and protocol input filters.
> + * Pulls from r->proto_input_filters instead of r->input_filters for
> + * stricter protocol adherence and better input filter behavior during
> + * chunked trailer processing (for http).
> + */
> +AP_DECLARE(apr_status_t) ap_rgetline_core(char **s, apr_size_t n,
> +  apr_size_t *read, request_rec *r,
> +  int flags, apr_bucket_brigade *bb)
> +{
> +return ap_fgetline_impl(s, n, read, r->proto_input_filters, flags,
> +bb, r->pool);
> +}
> +
>  #if APR_CHARSET_EBCDIC
>  AP_DECLARE(apr_status_t) ap_rgetline(char **s, apr_size_t n,
>   apr_size_t *read, request_rec *r,
> - int fold, apr_bucket_brigade *bb)
> + int flags, apr_bucket_brigade *bb)
>  {
>  /* on ASCII boxes, ap_rgetline is a macro which simply invokes
>   * ap_rgetline_core with the same parms
> @@ -532,8 +558,9 @@ AP_DECLARE(apr_status_t) ap_rgetline(cha
>   */
>  apr_status_t rv;
>  
> -rv = ap_rgetline_core(s, n, read, r, fold, bb);
> -if (rv == APR_SUCCESS || APR_STATUS_IS_ENOSPC(rv)) {
> +rv = ap_fgetline_impl(s, n, read, r->proto_input_filters, flags,
> +  bb, r->pool);
> +if (*read) {
>  ap_xlate_proto_from_ascii(*s, *read);
>  }
>  return rv;
> @@ -542,7 +569,6 @@ AP_DECLARE(apr_status_t) ap_rgetline(cha
>  
>  AP_DECLARE(int) ap_getline(char *s, int n, request_rec *r, int flags)
>  {
> -char *tmp_s = s;
>  apr_status_t rv;
>  apr_size_t len;
>  apr_bucket_brigade *tmp_bb;
> @@ -553,7 +579,8 @@ AP_DECLARE(int) ap_getline(char *s, int
>  }
>  
>  tmp_bb = apr_brigade_create(r->pool, r->connection->bucket_alloc);
> -rv = ap_rgetline(_s, n, , r, flags, tmp_bb);
> +rv = ap_fgetline_impl(, n, , r->proto_input_filters, flags,
> +  tmp_bb, r->pool);

Hm, now ap_getline is no longer EBCDIC agnostic. Is this intended?

Regards

Rüdiger

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

[William A Rowe Jr]

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 source world has gone to a more canonical
> semver.  I think we should generally align with that.
> 
>
> As an outcome, that would mean more major & minor releases, and less
> patch releases.  I think that if we break an existing ABI, we need to
> bump the major.  I think other projects are successfully doing this,
> and it has little effect on how distributions are packaging their
> projects.  Distros pick a point in time, whatever the current
> major.minor.patch is.

According to my math and history here, which begins with binary stability
(and not much feature changes in the period) at 1.3.14, and continuing
throughout all of 2.0/2.2/2.4...

Those would have been counted, using any semver scheme, as 2.0+++, 3.0+++,
4.0+++. Over the span of 18 years.

That would put us at approaching 5.0.0, with discussion of refactoring how
our URI's can successfully handle %CH entities correctly and finally close
a group of (now mitigated but still broken) security issues. Mop up some
other crufty bits in the process. Perhaps achieve 99.9% source
compatibility with judicious use of compatibility macros.

2.0+ major revisions (ABI stable-ish) persisted over 6 years each. That
isn't terribly shabby. Future majors would be even less frequent, as the
framework proves durable.

Pretend we are at 4.x, what would be our minor? I count only 21 releases in
2.4.x and 3 of those were immediate reactions to busted releases. That
corresponds to releasing 4.17.1 in the span of 6 years. (I'm not suggesting
renumbering, obviously... only trying to frame our project in semver terms
to test if this would be helpful or harmful.)

About 3 minor releases per year, and even that was perhaps too infrequent.
The subversion bug-fix releases were certainly too infrequent, we shouldn't
have waited so long on the fixes, but new development, and yes, refactoring
also slow us down a lot.

Thanks for the observations!

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

[Jim Riggs]

> 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? 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?
> 
> Luca is working PR 62102 which has to do with "syslog:...:...", but that 
> unveiled an inconsistency between core.c and log.c. Before his proposed patch 
> in STATUS, core.c is doing a strcmp() for "syslog" whereas log.c is doing 
> strncasecmp(). We have been discussing standardizing both on strn?cmp(), but 
> that would potentially lead to "breaking" configs that use "SYSLOG" rather 
> than "syslog".
> 
> 
> I don't believe that they two things are separate (core/log.c), since the 
> former checks for ErrorLog's parameter sanity and the latter sets it, so it 
> would be weird in my opinion if the two logic were different. This is why I 
> liked your consistency proposal Jim, and applied to my patch. In our docs we 
> clearly specify to use "syslog" in lowercase, so as far as I can see it using 
> "SYSLOG" would not be something that people should use..

Agreed, and I believe we should go forward with this. I just wanted to at least 
bring it up, since regressions and breaking existing configs has been a touchy 
subject lately. :-)

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

[Paul Querna]

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 align with that.


As an outcome, that would mean more major & minor releases, and less
patch releases.  I think that if we break an existing ABI, we need to
bump the major.  I think other projects are successfully doing this,
and it has little effect on how distributions are packaging their
projects.  Distros pick a point in time, whatever the current
major.minor.patch is.


On Fri, Apr 20, 2018 at 5:04 AM, Micha Lenk  wrote:
> 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 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 to
> distinguish between bugfix-only releases and feature addition releases.
>
> This does not mean that a minor bump needs to happen at almost every
> release. But not bumping the minor for years (which seems to be the current
> pattern of the httpd project) is just worse, because it increases the
> incentive to squeeze features like h2 into releases that are meant (or
> perceived) as bugfix-only releases.
>
> Regards,
> Micha

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

[Luca Toscano]

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
> >
> >   ErrorLog "syslog-httpd.log"
> >
> > that the current implementation would, incorrectly, send the log data to
> syslogd. Is that right?
>
> Luca is working PR 62102 which has to do with "syslog:...:...", but that
> unveiled an inconsistency between core.c and log.c. Before his proposed
> patch in STATUS, core.c is doing a strcmp() for "syslog" whereas log.c is
> doing strncasecmp(). We have been discussing standardizing both on
> strn?cmp(), but that would potentially lead to "breaking" configs that use
> "SYSLOG" rather than "syslog".
>
>
I don't believe that they two things are separate (core/log.c), since the
former checks for ErrorLog's parameter sanity and the latter sets it, so it
would be weird in my opinion if the two logic were different. This is why I
liked your consistency proposal Jim, and applied to my patch. In our docs
we clearly specify to use "syslog" in lowercase, so as far as I can see it
using "SYSLOG" would not be something that people should use..

Luca

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

[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
> 
>   ErrorLog "syslog-httpd.log"
> 
> that the current implementation would, incorrectly, send the log data to 
> syslogd. Is that right?

Luca is working PR 62102 which has to do with "syslog:...:...", but that 
unveiled an inconsistency between core.c and log.c. Before his proposed patch 
in STATUS, core.c is doing a strcmp() for "syslog" whereas log.c is doing 
strncasecmp(). We have been discussing standardizing both on strn?cmp(), but 
that would potentially lead to "breaking" configs that use "SYSLOG" rather than 
"syslog".

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

[Jim Jagielski]

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 good idea to suggest a tried-and-true 
> alternative defined by the Apache Subversion project, and documented 
> extensively at [1].
> 
> That is a lot to wade through, and parts just don't apply ... but even 
> reading some of that could be helpful when read as a comparative point to how 
> HTTPD historically does its T and branch/release management. That 
> Subversion "manual" on releases is very stable, and what we've been 
> doing/developed during our 18 years, especially with the project's 
> understanding of version control, and svn specifically :-)
> 
> Read the "Stabilizing and maintaining releases" section at a minimum, please. 
> That is kind of core to some of the issues on the mailing list recently, and 
> it describes how Subversion does things.
> 
> I don't want to write a tome, but to begin a discussion to adopt that 
> documented approach with tweaks for httpd. So to write a shorter note, I'd 
> basically summarize as:
> 
> * all development occurs on trunk
> * release branches are made off trunk for each MINOR release (see the 1.$N.x 
> branches at [2])
> * stabilization occurs on release branches by only cherry-picking existing 
> work/changes off of trunk
> * when a release branch is made, trunk's version is bumped (ie. say trunk is 
> 2.5, the 2.6.x branch is made, then trunk becomes 2.7)
> * IMO, don't bother making 2.7.x releases; just use the number to determine 
> if somebody grabbed a snapshot of trunk (svn happens to be 1.11.0-dev in 
> trunk, and will become 1.12.0-dev once the 1.11.x branch is made; the svn 
> project looks for a reported version of "-dev" for such snapshot behavior) 
> ... if you're going to think about a 2.7.x "test" release, then just make it 
> 2.8.x instead and label the feature experimental.
> * trunk is always stable and passes buildbot tests
> * version numbers are cheap, feel free to burn them (see our CHANGES[3] where 
> many specific numbers are recorded as "Not released")
> * Subversion has its own compatibility declarations defined around 
> major/minor; I'd suggest skip that and stick to the existing HTTPD "MMN" 
> system
> 
> I think that is most of the highlights. Again: I'd suggest reading the 
> section on Stabilization, and maybe "Creating and maintaining release 
> branches" section. The whole page for extra credit :-)
> 
> Cheers,
> -g
> 
> [1] http://subversion.apache.org/docs/community-guide/releasing.html 
> 
> [2] http://svn.apache.org/repos/asf/subversion/branches/ 
> 
> [3] http://svn.apache.org/repos/asf/subversion/trunk/CHANGES 
> 
> 

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

[Jim Jagielski]

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

[Greg Stein]

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 extensively at [1].

That is a lot to wade through, and parts just don't apply ... but even
reading some of that could be helpful when read as a comparative point to
how HTTPD historically does its T and branch/release management. That
Subversion "manual" on releases is very stable, and what we've been
doing/developed during our 18 years, especially with the project's
understanding of version control, and svn specifically :-)

Read the "Stabilizing and maintaining releases" section at a minimum,
please. That is kind of core to some of the issues on the mailing list
recently, and it describes how Subversion does things.

I don't want to write a tome, but to begin a discussion to adopt that
documented approach with tweaks for httpd. So to write a shorter note, I'd
basically summarize as:

* all development occurs on trunk
* release branches are made off trunk for each MINOR release (see the
1.$N.x branches at [2])
* stabilization occurs on release branches by only cherry-picking existing
work/changes off of trunk
* when a release branch is made, trunk's version is bumped (ie. say trunk
is 2.5, the 2.6.x branch is made, then trunk becomes 2.7)
* IMO, don't bother making 2.7.x releases; just use the number to determine
if somebody grabbed a snapshot of trunk (svn happens to be 1.11.0-dev in
trunk, and will become 1.12.0-dev once the 1.11.x branch is made; the svn
project looks for a reported version of "-dev" for such snapshot behavior)
... if you're going to think about a 2.7.x "test" release, then just make
it 2.8.x instead and label the feature experimental.
* trunk is always stable and passes buildbot tests
* version numbers are cheap, feel free to burn them (see our CHANGES[3]
where many specific numbers are recorded as "Not released")
* Subversion has its own compatibility declarations defined around
major/minor; I'd suggest skip that and stick to the existing HTTPD "MMN"
system

I think that is most of the highlights. Again: I'd suggest reading the
section on Stabilization, and maybe "Creating and maintaining release
branches" section. The whole page for extra credit :-)

Cheers,
-g

[1] http://subversion.apache.org/docs/community-guide/releasing.html
[2] http://svn.apache.org/repos/asf/subversion/branches/
[3] http://svn.apache.org/repos/asf/subversion/trunk/CHANGES

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

[Jim Jagielski]

> 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 SYSLOG: today it is broken when you hit core, which ignores
> that code path. Since the behavior has always been syslog: I'm
> not seeing a benefit to case insensitivity.

macOS is typically case aware but not necessarily case sensitive.

For example, both

/tmp/foobarski

and

/tmp/FooBARskI

are seen as the same file, but case is maintained.

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

[Jim Riggs]

> 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 seconds. 
> ;-)
> 
> 
> Thanks a lot! I added your last suggestions to r1829626 and also a CHANGES 
> entry. I tested it on my local environment and it seems working fine, let me 
> know if everything looks good or if anything is missing.

I'm fine with it, *BUT* in light of our recent discussions about 
backports/fixes causing regressions in existing configs, this could cause 
another. I agree with what we have done in this patch, but we could potentially 
break existing configs, no? For example:

ErrorLog "SYSLOG"

This will send to syslog before the patch but will send to file 
/SYSLOG after. Ugh. So, should we not touch server/log.c???

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

[Jim Jagielski]

> 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 too many variants of versioning schemes out 
> there in use by so many OSS projects that the distributors and vendors need 
> to be prepared to encounter any variant you can imagine.
> 

We have a history, as well as a published "agreement" on what minor version 
numbering means. Our module eco-system is huge and we need to factor/consider 
not only the big players, but also the solitary developers who have modules. It 
is a long, long history and if/when we need to reconsider versioning, the 
impact will not be insignificant.

> What matters is quality (here I do agree with you). A versioning scheme can 
> help to establish certain rules of what to do and more importantly what to 
> *not* do on a given version pattern or branch. And with the current rate of 
> successful releases, apparently the current rules either were not enforced 
> well enough or otherwise were not good enough and thus need to be changed. A 
> new versioning scheme then could help to establish new, hopefully better 
> rules.

Or just change the goalposts... if, as you say, our current version-scheme 
rules don't work as far as limiting/controlling what we can do (which I don't 
agree with, btw), then simply replacing it with another version-scheme likely 
won't do anything as well.

Again, I don't think numbers or names are the issue at hand, at core, but 
rather, maybe, overconfidence in how we have been doing release QA and testing. 
For example, and I am certainly guilty of this, the original concept was that 
"new stuff" was put in trunk, and allowed to mellow and age, for a "bit" at 
least, to get a feel for how well it works. After "awhile", when things looked 
like it was "ready for prime time", it would be proposed for backport. Today, 
right after something is committed to trunk there is almost invariably, in the 
next commit, a backport proposal for it to be in 2.4. Now for bug fixes, etc, 
that likely makes some level of sense, but lately, it seems like committing to 
trunk is just a tic-mark.

Again, it is all in balance, and likely we've just not achieved that lately due 
to the extreme complexities of the eco-system around, internal, external and 
dependent upon us.

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

[Micha Lenk]

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 that the distributors and 
vendors need to be prepared to encounter any variant you can imagine.


What matters is quality (here I do agree with you). A versioning scheme 
can help to establish certain rules of what to do and more importantly 
what to *not* do on a given version pattern or branch. And with the 
current rate of successful releases, apparently the current rules either 
were not enforced well enough or otherwise were not good enough and thus 
need to be changed. A new versioning scheme then could help to establish 
new, hopefully better rules.


Just my 2¢.

Regards,
Micha

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

[Jim Jagielski]

> 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 to 
> distinguish between bugfix-only releases and feature addition releases.
> 

I understand that, thx. I also understand how a minor bump makes that easier. 
It would make, however, other people's lives and jobs *more* difficult, I 
think, so it's all about balance. I can see how distinguishing the difference 
is also nice, but what "value" do you derive from it? I am genuinely curious. 
Thx!

This is a "hack", of course, but what if CHANGES specifically called out new 
features like we do w/ SECURITY items?

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

[Micha Lenk]

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 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 to distinguish between bugfix-only releases and feature addition 
releases.


This does not mean that a minor bump needs to happen at almost every 
release. But not bumping the minor for years (which seems to be the 
current pattern of the httpd project) is just worse, because it 
increases the incentive to squeeze features like h2 into releases that 
are meant (or perceived) as bugfix-only releases.


Regards,
Micha

Re: "Most Popular Web Server?"

[Jim Jagielski]

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

[Rainer Jung]

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 lead to httpd event MPM processes hanging
during process shutdown.  PR 61786.  [Yann Ylavic]



Never hurts, but it is just Solaris isn't it?


I think so for the CHANGES topic (ports impl of poll), although there 
were more changes in the backport commit for which I'm not sure about 
how important they are and when they apply.


Regards,

Rainer

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

[Jim Jagielski]

> 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 it again till 4.0?

Doesn't that break our understanding/"contract" with all external module 
developers and ISV? Up until now, minor has always indicated ABI changes which 
means, real world, you need to provide a different module build for each minor 
version. Now we would be saying "Nope, not in this case"

That seems, to me, worse than what we have now. Plus, it does nothing to 
satisfy the concerns about "quality" of what is released in any way.

Again, IMO, it's not about numbers, or what we call it, for US. It about QA, 
testing and being more sensitive to regression and wholesale refactoring on 
stuff that is going to be released. Where numbers and versioning DOES matter is 
how it affects distributors and vendors of httpd and the entire module 
eco-system.

Just my 2c

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

[Jim Jagielski]

> 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 matter that h2 was added in 2.4.x instead of
a 2.6.0? Every new feature must bump the minor? Even if
there is no corresponding ABI issue?

You wrote:
  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.

h2 was a '"brand new, try it out" subproject', external
to httpd. It was brought in via a generous donation of
code and because there was a desire and "need" for it to
be an official part of the distro.

In general, even though PHP says that all "New feature"
must be in a Minor bump, this has not ever been the
case for httpd. Otherwise we'd be up to version 2.223.x
by now, after having left version 1.6542.x :)

And finally, it's not quite apples/apples comparing
language version numbering to *server software* versioning,
especially when there is a large, external module eco-system
for the server software that relies on the minor number
being "only" ABI related.

Re: "Most Popular Web Server?"

[Rich Bowen]

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, 3rd party effort) in in conjunction
> w/ the blog posts or instead of it.
>

Rewinding to this idea, I think this is the right move.

Do we actually want to resurrect apacheweek.com?  Looks like that's a red
hat property now. Perhaps Mark Cox owns it? Or do we want to aim at the
blog site and twitter instead?

I think we'd have no trouble finding monthly articles. Weekly might be a
challenge to work up to.

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?

>

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

[Eric Covener]

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

[Eric Covener]

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  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 r1829643).
>>
>> Regarding the code change itself (!proxyreq => proxyreq !=
>> PROXYREQ_RESPONSE), I think this is the right thing to do because
>> otherwise we don't limit proxyied *request* bodies. Actually I had
>> this patch locally for a while, just noticing it now by adding the
>> ap_rgetline() stuff (that I need to "release" ASAP :) . Will re-check
>> if this is the case.
>>
>> This change is possibly not backportable to 2.4 though.
>
> It rings a bell, I  only meant I had not really thought about the
> change not that it was suspicious, sorry for the wording.
> I think i actually initiated a thread about this confusing choice many
> years ago, I will see if I can dig it up.
>
>
> --
> Eric Covener
> cove...@gmail.com



-- 
Eric Covener
cove...@gmail.com

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

[Eric Covener]

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 LimitRequestBody?
>
> Yes indeed, I made a confusion here (comment restored in r1829643).
>
> Regarding the code change itself (!proxyreq => proxyreq !=
> PROXYREQ_RESPONSE), I think this is the right thing to do because
> otherwise we don't limit proxyied *request* bodies. Actually I had
> this patch locally for a while, just noticing it now by adding the
> ap_rgetline() stuff (that I need to "release" ASAP :) . Will re-check
> if this is the case.
>
> This change is possibly not backportable to 2.4 though.

It rings a bell, I  only meant I had not really thought about the
change not that it was suspicious, sorry for the wording.
I think i actually initiated a thread about this confusing choice many
years ago, I will see if I can dig it up.


-- 
Eric Covener
cove...@gmail.com

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

[Yann Ylavic]

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 r1829643).

Regarding the code change itself (!proxyreq => proxyreq !=
PROXYREQ_RESPONSE), I think this is the right thing to do because
otherwise we don't limit proxyied *request* bodies. Actually I had
this patch locally for a while, just noticing it now by adding the
ap_rgetline() stuff (that I need to "release" ASAP :) . Will re-check
if this is the case.

This change is possibly not backportable to 2.4 though.

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

[Eric Covener]

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 PROXYREQ_REVERSE in ap_http_filter(),
> we are still handling the request, not the response where LimitRequestBody
> does not apply.
>
>
> Modified:
> httpd/httpd/trunk/CHANGES
> httpd/httpd/trunk/modules/http/http_filters.c
>
> Modified: httpd/httpd/trunk/CHANGES
> URL: 
> http://svn.apache.org/viewvc/httpd/httpd/trunk/CHANGES?rev=1829642=1829641=1829642=diff
> ==
> --- httpd/httpd/trunk/CHANGES [utf-8] (original)
> +++ httpd/httpd/trunk/CHANGES [utf-8] Fri Apr 20 09:46:51 2018
> @@ -1,6 +1,8 @@
>   -*- coding: utf-8 
> -*-
>  Changes with Apache 2.5.1
>
> +  *) http: LimitRequestBody applies to proxied requests.  [Yann Ylavic]
> +
>*) mod_proxy_http: Fix response header thrown away after the previous one
>   was considered too large and truncated. PR 62196. [Yann Ylavic]
>
>
> Modified: httpd/httpd/trunk/modules/http/http_filters.c
> URL: 
> http://svn.apache.org/viewvc/httpd/httpd/trunk/modules/http/http_filters.c?rev=1829642=1829641=1829642=diff
> ==
> --- httpd/httpd/trunk/modules/http/http_filters.c (original)
> +++ httpd/httpd/trunk/modules/http/http_filters.c Fri Apr 20 09:46:51 2018
> @@ -317,12 +317,11 @@ apr_status_t ap_http_filter(ap_filter_t
>  f->ctx = ctx = apr_pcalloc(f->r->pool, sizeof(*ctx));
>  ctx->state = BODY_NONE;
>
> -/* LimitRequestBody does not apply to proxied responses.
> +/* LimitRequestBody does not apply to proxied responses, which have
> + * their own ResponseFieldSize parameter.


Not sure about change but re: comment

Are those comparable? The new proxy parm ResponseFieldSize is like
LimitRequestFieldSize not LimitRequestBody?

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

[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 lead to httpd event MPM processes hanging
>during process shutdown.  PR 61786.  [Yann Ylavic]


Never hurts, but it is just Solaris isn't it?

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

[William A Rowe Jr]

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 is still true today.
>
> If that is a concern, it would be better to check and if needed start an
> independent discussion thread for that.

The logic I pointed Jeff at has four orientations, stable, candidate, snapshot
and bleed (for future revs, e.g. trunk/ across the board.)

What oss-httpd-build doesn't do (at least not yet) are all the permutations
of very old components, e.g. APR gen 1.4.x + httpd. I don't have enough
cycles to tackle it all, but as the Makefile.checkout phase is enhanced,
that's one really interesting aspect to consider (1.4.x gen, 1.5.x gen, the
current 1.6.x gen and eventually 1.7.x APR.)

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

[Mark Blackman]

> 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 hit a situation where 2.6 (as a release
> branch) can't get a feature or the next great thing because of a
> required API incompatible change. We would then kick out 2.8, 2.10 and
> so on and so forth. This seems like it would satisfy both the
> keep-the-stuff-stable as well as the give-users-new-stuff "sides".
> 
> 
> Mechanically, this can become tiresome for a volunteer as we work
> through the STATUS ceremony for each of the branches. I remember that
> being less than enjoyable when 2.0, 2.2 and 2.4 were all release
> branches. I'm fearful of a future where we may have five branches and a
> bugfix applicable to all (or worse... a security fix that would dictate
> all should be released/disclosed at the same time).

Presumably most/all of that toil can be automated away as you have started 
doing, so that human intervention is only required where human judgement is 
actually required?  Does httpd have some massive CD/CI pipeline in the 
background I don’t see or could it do with one? 

- Mark

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

[Ruediger Pluem]

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 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.
>>>
>>> Would you define an RC? What changes are allowable in that branch?
>>
>>
>> The idea is that right now we take an existing state in SVN
>> and tag it as, for example, 2.4.121. We then vote on that tag
>> and the artifacts released from that tag. No work is done on
>> the 2.4 branch while testing is done so that we ensure that
>> the SVN rev on branch == the one for the tag.
>>
>> Instead, we tag at 2.4.121-RC1. We do the exact same. If the
>> vote does not pass, we continue on the 2.4 branch, fix the
>> issues, and then tag a 2.4.121-RC2. Rinse and repeat.
>>
>> If the vote does pass we tag the branch, which is still == RC#
>> at this stage, as 2.4.121 (ap_release.h mods included). We
>> still even at this stage test and vote on the release as we have
>> for decades. If it passes, we release. If not, for some reason,
>> we have burned the 2.4.121 release, bump to 2.4.122 and GOTO
>> the above.
>>
>> This is the overall idea... more flesh to be added.
> 
> IMHO we should aim at keeping the RC phase as stable as possible and focuse 
> on the code from which we tagged RC1 and
> which we actually want to release. So after RC1 there should be only fixes 
> for regressions, no other fixes or backports.
> 
> Other projects for example branch at the start of the release process (using 
> your version example 2.4.121 here):
> 
> - branch 2.4.x as a 2.4.121 branch
> - tag 2.4.121-RC1 on that branch
> - allow for a week or two (?) of public testing
> - fix incoming regressions
>   - patches go via trunk to 2.4.x to 2.4.121 branch
> - cut new RCs if previous RC needed fixes
> - create final release tag from last RC plus some script driven version 
> adjustments
> - do final release vote

+1. Sounds reasonable, gives more time for testing avoids freezes on the 2.4.x 
branch while keeping the RC stable. Let's
try this and see the results.

Regards

Rüdiger

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

[Rainer Jung]

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 occasionally lead to httpd event MPM processes hanging
during process shutdown.  PR 61786.  [Yann Ylavic]


That's an interesting question, would you propose a release to the APR
developer's list?


I will, but I wanted to first check this from the point of view of hte 
httpd project as a consumer of APR/APU and as a topic that might 
influence release timing.



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 is still true today.


If that is a concern, it would be better to check and if needed start an 
independent discussion thread for that.


Regards,

Rainer

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

[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 occasionally lead to httpd event MPM processes hanging
>during process shutdown.  PR 61786.  [Yann Ylavic]

That's an interesting question, would you propose a release to the APR
developer's list? 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 is still true today.

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

[Rainer Jung]

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:



Merge r1819857, r1819858, r1819860, r1819861, r1819934, r1819935 from trunk:

testpoll: check that the wakeup pipe is still in the pollset after 
returning from poll(), e.g. APR_POLLSET_PORT should re-arm it automatically.



poll, port: re-add the wakeup pipe to the pollset after it triggered.

Just like user fds (file, socket), otherwise it's one shot only (PR-61786).

Corresponding test committed in r1819857.


poll, port: no need to release and re-acquire the lock in between 
walking the pollset and handling the dead ring, all is 
simple/fast/nonblocking ops.


Also, set types of "i" and "j" respectively to the ones of nget and *num.


poll, port: follow up to r1819860.

This test is redundant now, axe it (no functional change).


poll, kqueue: save a pollfd (mem)copy per returned event.


poll, epoll: pollset's pfd is not modified on poll(), mark it const.




At least on Solaris this looks useful. Or do we think that change is to 
big to put it into the deps tarball?



And for APR-Util there is r1825312. From CHANGES:

*) apr_dbm_gdbm: Fix handling of error codes. This makes gdbm 1.14 work.
   apr_dbm_gdbm will now also return error codes starting with
   APR_OS_START_USEERR, as apr_dbm_berkleydb does, instead of always
   returning APR_EGENERAL. [Stefan Fritsch]

and from the commit log:



Fix error handling in gdbm

Only check for gdbm_errno if the return value of the called gdbm_*
function says so. This fixes apr-util with gdbm 1.14, which does not
seem to always reset gdbm_errno.

Also make the gdbm driver return error codes starting with
APR_OS_START_USEERR instead of always returning APR_EGENERAL. This is
what the berkleydb driver already does.

Also ensure that dsize is 0 if dptr == NULL.

(backport of r1825311 in apr trunk)



The risk of breaking things is formally smaller, because builders can 
always switch back to the old dependency tarball without the need for a 
new httpd release, although that situation would produce a bit of confusion.


Regards,

Rainer

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

[Luca Toscano]

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 also a CHANGES
entry. I tested it on my local environment and it seems working fine, let
me know if everything looks good or if anything is missing.

Luca