Re: [VOTE] Release httpd-2.4.30

[Daniel Ruggeri]

All;
   With the release issues identified during validation, we will call this vote 
CLOSED with the statement that 2.4.30 is not suitable for public release. I 
apologise for the clerical error in not noting this sooner.

On 2018/02/19 14:54:35,  wrote: 
> Hi, all;
> 
>Please find below the proposed release tarball and signatures:
> 
> https://dist.apache.org/repos/dist/dev/httpd/
> 
>  
> 
> I would like to call a VOTE over the next few days to release this candidate
> tarball as 2.4.30:
> 
>  
> 
> [ ] +1: It's not just good, it's good enough!
> 
> [ ] +0: Let's have a talk.
> 
> [ ] -1: There's trouble in paradise. Here's what's wrong.
> 
> -- 
> 
> Daniel Ruggeri
> 
>  
> 
> 

Re: [VOTE] Release httpd-2.4.30

[Jim Jagielski]

It likely makes sense to CLOSE this vote with the
result that 2.4.30 is not being released...

> On Feb 19, 2018, at 9:54 AM, drugg...@primary.net wrote:
> 
> Hi, all;
>Please find below the proposed release tarball and signatures:
> https://dist.apache.org/repos/dist/dev/httpd/ 
> 
>  
> I would like to call a VOTE over the next few days to release this candidate 
> tarball as 2.4.30:
>  
> [ ] +1: It’s not just good, it’s good enough!
> [ ] +0: Let’s have a talk…
> [ ] -1: There’s trouble in paradise. Here’s what’s wrong.
> -- 
> Daniel Ruggeri

Re: [VOTE] Release httpd-2.4.30

[Stefan Eissing]

Wow! Nice work!

> Am 21.02.2018 um 21:34 schrieb Rainer Jung :
> 
> Am 19.02.2018 um 15:54 schrieb drugg...@primary.net:
>> Hi, all;
>>Please find below the proposed release tarball and signatures:
>> https://dist.apache.org/repos/dist/dev/httpd/
>> I would like to call a VOTE over the next few days to release this candidate 
>> tarball as 2.4.30:
>> [ ] +1: It’s not just good, it’s good enough!
>> [ ] +0: Let’s have a talk…
>> [ ] -1: There’s trouble in paradise. Here’s what’s wrong.
> 
> -1 to release due to the flaws found by others. But we should be good with 
> 2.4.31. Please update APR/APU in the deps tarball.
> 
> Detailed report:
> 
> - Sigs and hashes OK
> - contents of tarballs identical
> - contents of tag and tarballs identical
>  except for expected deltas
> - deps convenience tarball does not contain latest APR/APU 1.6.3/1.6.1
>  -> please update
> 
> Built on
> 
> - Solaris 10 Sparc as 32 Bit Binaries
> - SLES 11+12 (64 Bits)
> - RHEL 6+7 (64 Bits)
> 
> For all platforms built
> 
> - with default (shared) and static modules
> - with module set reallyall
> - using --enable-load-all-modules
> - against "included" APR/APU from deps tarball,
>  plus external APR/APU 1.6.3/1.6.1 and 1.5.2/1.5.4
> 
> - using external libraries
>  - expat 2.2.5
>  - pcre 8.41
>  - openssl 1.0.2n plus patches
>  - lua 5.3.4 (compiled with LUA_COMPAT_MODULE)
>  - distcache 1.5.1
>  - libxml2 2.9.7
>  - libnghttp2 1.30.0
>  - brotli 1.0.2
>  - curl 7.58.0
>  - jansson 2.10
> 
> - Tool chain:
>- platform gcc except on Solaris
>  (gcc 7.3.0 Solaris 10, only older APR/APU 1.5.x compiled with older gcc 
> 4.9.2)
>- CFLAGS: -O2 -g -Wall -fno-strict-aliasing
>  - on Solaris additionally -mpcu=v9, -D_XOPEN_SOURCE,
>-D_XOPEN_SOURCE_EXTENDED=1, -D__EXTENSIONS__
>and -D_XPG6
> 
> All 40 builds succeeded.
> 
> - compiler warnings:
> 
>  - modules/core/mod_watchdog.c:436: warning: 'rv' may be used
>uninitialized in this function
>  -> warning is correct but not critical (debug log);
> not a regression
> 
>  on RHEL 6 and SLES 11 due to older GCC versions:
> 
>  - modules/md/md_json.c:31: warning: expected [error|warning|ignored] after 
> '#pragma GCC diagnostic'
> 
>  - modules/md/md_json.c:45: warning: expected [error|warning|ignored] after 
> '#pragma GCC diagnostic'
> 
>  due to strange jansson dependency library header files:
> 
> include/jansson.h:117:6: warning: 'json_decrefp' defined but not used 
> [-Wunused-function]
> include/jansson.h:187:5: warning: 'json_object_set_nocheck' defined but not 
> used [-Wunused-function]
> include/jansson.h:193:5: warning: 'json_object_iter_set' defined but not used 
> [-Wunused-function]
> include/jansson.h:208:5: warning: 'json_array_set' defined but not used 
> [-Wunused-function]
> include/jansson.h:220:5: warning: 'json_array_insert' defined but not used 
> [-Wunused-function]
> 
>  and only on Solaris (gcc 7.3.0)
> 
>  - modules/ldap/util_ldap_cache_mgr.c:728:32: warning: format '%ld' expects 
> argument of type 'long int', but argument 6 has type 'long long int' 
> [-Wformat=]
> 
>  - modules/ldap/util_ldap_cache.c:111:20: warning: format '%ld' expects 
> argument of type 'long int', but argument 8 has type 'long long int' 
> [-Wformat=]
> 
>  - srclib/apr-util/xlate/xlate.c:120:38: warning: passing argument 2 of
>'iconv' from incompatible pointer type
>[-Wincompatible-pointer-types]
> 
>  - srclib/apr-util/xlate/xlate.c:343:42: warning: passing argument 2 of
>'iconv' from incompatible pointer type
>[-Wincompatible-pointer-types]
> 
> 
> Tested for
> 
> - Solaris 10, SLES 11+12, RHEL 6+7
> - MPMs prefork, worker, event
> - default and static modules
> - log levels info, debug and trace8
> - module set reallyall (127 modules plus MPMs)
> 
> The following test failures were seen:
> 
> a Lots of tests in t/module/session.t fail always for static builds.
>  Not a regression.
>  For 2.4.28 the analysis was:
>  The whole setup for the /sessiontest uri is missing in the generated
>  t/conf/httpd.conf. This is due to it missing from the also generated
>  filet/conf/apache_test_config.pm. I do not know yet, why it is missing
>  there, but this seems to be a test framework problem.
> 
> b Test 59 of t/modules/include.t only and always on
>  Solaris.
>  Not a regression
>  Old analysis was:
>  This is due to a bug in the test, which uses strftime()
>  with a "%s" pattern that is not supported on Solaris.
>  Until recently the server and the test client both returned
>  verbatim "%s" and the test succeeded. After updating some
>  Perl modules for the http2 tests, the perl client even
>  on Solaris now supports "%s" in strftime and the test starts
>  to fail. It seems we have to fix the test.
> 
> c Various tests in t/apache/expr_string.t
>  Not a regression.
>  Test numbers : 6, 11, 14, 17, 20, 23, 26, 29
>  Happens for 9 out of about 225 runs (8 times on RHEL6, once
>  on Solaris).
>  The failure is almost always on line 87, where 

Re: [VOTE] Release httpd-2.4.30

[Rainer Jung]

Am 19.02.2018 um 15:54 schrieb drugg...@primary.net:

Hi, all;

    Please find below the proposed release tarball and signatures:

https://dist.apache.org/repos/dist/dev/httpd/

I would like to call a VOTE over the next few days to release this 
candidate tarball as 2.4.30:


[ ] +1: It’s not just good, it’s good enough!

[ ] +0: Let’s have a talk…

[ ] -1: There’s trouble in paradise. Here’s what’s wrong.


-1 to release due to the flaws found by others. But we should be good 
with 2.4.31. Please update APR/APU in the deps tarball.


Detailed report:

- Sigs and hashes OK
- contents of tarballs identical
- contents of tag and tarballs identical
  except for expected deltas
- deps convenience tarball does not contain latest APR/APU 1.6.3/1.6.1
  -> please update

Built on

- Solaris 10 Sparc as 32 Bit Binaries
- SLES 11+12 (64 Bits)
- RHEL 6+7 (64 Bits)

For all platforms built

- with default (shared) and static modules
- with module set reallyall
- using --enable-load-all-modules
- against "included" APR/APU from deps tarball,
  plus external APR/APU 1.6.3/1.6.1 and 1.5.2/1.5.4

- using external libraries
  - expat 2.2.5
  - pcre 8.41
  - openssl 1.0.2n plus patches
  - lua 5.3.4 (compiled with LUA_COMPAT_MODULE)
  - distcache 1.5.1
  - libxml2 2.9.7
  - libnghttp2 1.30.0
  - brotli 1.0.2
  - curl 7.58.0
  - jansson 2.10

- Tool chain:
- platform gcc except on Solaris
  (gcc 7.3.0 Solaris 10, only older APR/APU 1.5.x compiled with 
older gcc 4.9.2)

- CFLAGS: -O2 -g -Wall -fno-strict-aliasing
  - on Solaris additionally -mpcu=v9, -D_XOPEN_SOURCE,
-D_XOPEN_SOURCE_EXTENDED=1, -D__EXTENSIONS__
and -D_XPG6

All 40 builds succeeded.

- compiler warnings:

  - modules/core/mod_watchdog.c:436: warning: 'rv' may be used
uninitialized in this function
  -> warning is correct but not critical (debug log);
 not a regression

  on RHEL 6 and SLES 11 due to older GCC versions:

  - modules/md/md_json.c:31: warning: expected [error|warning|ignored] 
after '#pragma GCC diagnostic'


  - modules/md/md_json.c:45: warning: expected [error|warning|ignored] 
after '#pragma GCC diagnostic'


  due to strange jansson dependency library header files:

include/jansson.h:117:6: warning: 'json_decrefp' defined but not used 
[-Wunused-function]
include/jansson.h:187:5: warning: 'json_object_set_nocheck' defined but 
not used [-Wunused-function]
include/jansson.h:193:5: warning: 'json_object_iter_set' defined but not 
used [-Wunused-function]
include/jansson.h:208:5: warning: 'json_array_set' defined but not used 
[-Wunused-function]
include/jansson.h:220:5: warning: 'json_array_insert' defined but not 
used [-Wunused-function]


  and only on Solaris (gcc 7.3.0)

  - modules/ldap/util_ldap_cache_mgr.c:728:32: warning: format '%ld' 
expects argument of type 'long int', but argument 6 has type 'long long 
int' [-Wformat=]


  - modules/ldap/util_ldap_cache.c:111:20: warning: format '%ld' 
expects argument of type 'long int', but argument 8 has type 'long long 
int' [-Wformat=]


  - srclib/apr-util/xlate/xlate.c:120:38: warning: passing argument 2 of
'iconv' from incompatible pointer type
[-Wincompatible-pointer-types]

  - srclib/apr-util/xlate/xlate.c:343:42: warning: passing argument 2 of
'iconv' from incompatible pointer type
[-Wincompatible-pointer-types]


Tested for

- Solaris 10, SLES 11+12, RHEL 6+7
- MPMs prefork, worker, event
- default and static modules
- log levels info, debug and trace8
- module set reallyall (127 modules plus MPMs)

The following test failures were seen:

a Lots of tests in t/module/session.t fail always for static builds.
  Not a regression.
  For 2.4.28 the analysis was:
  The whole setup for the /sessiontest uri is missing in the generated
  t/conf/httpd.conf. This is due to it missing from the also generated
  filet/conf/apache_test_config.pm. I do not know yet, why it is missing
  there, but this seems to be a test framework problem.

b Test 59 of t/modules/include.t only and always on
  Solaris.
  Not a regression
  Old analysis was:
  This is due to a bug in the test, which uses strftime()
  with a "%s" pattern that is not supported on Solaris.
  Until recently the server and the test client both returned
  verbatim "%s" and the test succeeded. After updating some
  Perl modules for the http2 tests, the perl client even
  on Solaris now supports "%s" in strftime and the test starts
  to fail. It seems we have to fix the test.

c Various tests in t/apache/expr_string.t
  Not a regression.
  Test numbers : 6, 11, 14, 17, 20, 23, 26, 29
  Happens for 9 out of about 225 runs (8 times on RHEL6, once
  on Solaris).
  The failure is almost always on line 87, where the error_log contents
  are checked.

d One single test run (RHEL 7) failed test 163 of t/ssl/proxy.t
  (line 131 of Apache-Test/lib/Apache/TestCommonPost.pm)

e Only on Solaris and only with prefork proxy tests sometimes
  seem to hang until timeout.
  Not a regression
  Some test 

Re: [VOTE] Release httpd-2.4.30

[Rainer Jung]

Am 19.02.2018 um 15:54 schrieb drugg...@primary.net:

Hi, all;

    Please find below the proposed release tarball and signatures:

https://dist.apache.org/repos/dist/dev/httpd/

I would like to call a VOTE over the next few days to release this 
candidate tarball as 2.4.30:


[ ] +1: It’s not just good, it’s good enough!

[ ] +0: Let’s have a talk…

[ ] -1: There’s trouble in paradise. Here’s what’s wrong.


My testing is still ongoing but one thing I noticed: the dependency 
tarball which we provide for convenience still contains APR/APU 
1.6.2/1.6.0, but recent versions would be 1.6.3/1.6.1.


Regards,

Rainer

Re: [VOTE] Release httpd-2.4.30

[William A Rowe Jr]

On Tue, Feb 20, 2018 at 6:06 AM, Jim Jagielski  wrote:
> -1: I think with the release process hiccups and the Win issues
> noted in the "Current branche 2.4.30-dev issues" thread,
> we will need a 2.4.31. Additionally, there are some
> backports in STATUS that could also be folded in.

Very sensible.

I think our odds of a successful 2.4.31 increase dramatically if the
community will please continue their 2.4.30 review as if it would
become the release. Hold off any re-spin for a couple days to allow
that to happen as it usually would.

If 2.4.31 remains relatively static vs. 2.4.30, it minimizes the number
of additional regressions, e.g. hold 2.4.x branch to showstoppers
or regression fixes of 2.4.29/2.4.30 only for a few days.

Reviewing a lightly modified 2.4.31 candidate becomes much
simpler if 2.4.30 candidate has been beaten on, sufficiently.

Re: [VOTE] Release httpd-2.4.30

[Jim Jagielski]

If we could see the tooling it might be easier to vet it.

> On Feb 20, 2018, at 8:39 AM, drugg...@primary.net wrote:
> 
>> -Original Message-
>> From: Jim Jagielski [mailto:j...@jagunet.com]
>> Sent: Tuesday, February 20, 2018 6:10 AM
>> To: dev@httpd.apache.org
>> Subject: Re: [VOTE] Release httpd-2.4.30
>> 
>> Another thing that helps is providing some heads-up
>> that a T&R will actually be happening... Yeah, you
>> had noted the you were going to T&R on Monday
>> (in the "T&R of 2.4.30 Proposal" thread) but sending
>> out a quick "I plan on doing this in X hours" notice
>> allows for some possible last-minute items to pop
>> up.
>> 
>> Just a suggestion.
> 
> Sure, I can do that.
> 
> 
>> 
>>> On Feb 19, 2018, at 9:44 PM, Jim Jagielski >> <mailto:j...@jagunet.com>> wrote:
>>> 
>>> I would suggest using the scripts from
>>> 
>>>https://svn.apache.org/repos/asf/httpd/site/trunk/tools 
>>> <https://svn.apache.org/repos/asf/httpd/site/trunk/tools>
>>> 
>>> for as much of the work as possible since they have been used
>>> and vetted for several years.
> 
> Indeed, I did for everything except the tagging (which is why I created a 
> script to do it). I also created one to push to dev/release dist repos for 
> convenience. As mentioned, the goal is to automate the process as much as 
> possible so with the gap in existing tooling, I went ahead and filled it. I 
> guess I just misinterpreted the instructions and didn’t think to review SVN 
> history of the previous releases as Joe mentioned.
> 
> Aside from this omission, are we otherwise in good shape?
> 
> 
>>> 
>>>> On Feb 19, 2018, at 7:28 PM, drugg...@primary.net wrote:
>>>> 
>>>> Ah, I see. I created a script that does the tagging based on the directions
>> here.
>>>> http://httpd.apache.org/dev/release.html
>>>> 
>>>> It was unclear in those instructions that one should commit the change to
>> AP_SERVER_DEVBUILD_BOOLEAN.
>>>> 
>>>> Instead I did the following:
>>>> ...
>>>> #Set AP_SERVER_DEVBUILD_BOOLEAN to 0 in include/ap_release.h.
>>>> perl -pi -e 's/(#define\s+AP_SERVER_DEVBUILD_BOOLEAN\s+)\d/${1}0/g'
>> include/ap_release.h
>>>> 
>>>> #Create an official X.Y.Z tag based on the candidate tree.
>>>> svn copy "$src_dir" "$tags_dir/$version"
>>>> 
>>>> #Revert the change to include/ap_release.h setting
>> AP_SERVER_DEVBUILD_BOOLEAN back to 1, and bump
>> AP_SERVER_PATCHLEVEL_NUMBER
>>>> perl -pi -e '
>>>> s/(#define\s+AP_SERVER_DEVBUILD_BOOLEAN\s+)\d/${1}1/g;
>>>> 
>>>> if(/(#define\s+AP_SERVER_PATCHLEVEL_NUMBER\s+)(\d+)$/){
>>>>   $new = $2 + 1;
>>>>   $_ = "${1}${new}\n";
>>>> }
>>>> ' include/ap_release.h
>>>> ...
>>>> 
>>>> This begets a tarball that has the Boolean set to 0, but no
>> commit/revert/bump (instead just an apparent bump):
>>>> 
>> http://svn.apache.org/viewvc/httpd/httpd/tags/2.4.30/include/ap_release.
>> h?view=markup#l47
>>>> 
>>>> It makes sense that the tag comes from a specific commit where the
>> variable was flipped...  Should I adjust the script and retry?
>>>> 
>>>> --
>>>> Daniel Ruggeri
>>>> 
>>>> From: Jim Jagielski [mailto:j...@jagunet.com]
>>>> Sent: Monday, February 19, 2018 9:46 AM
>>>> To: dev@httpd.apache.org
>>>> Subject: Re: [VOTE] Release httpd-2.4.30
>>>> 
>>>> Hmmm... I'm not seeing the patch where
>> AP_SERVER_DEVBUILD_BOOLEAN
>>>> in ap_release.h is set to 0
>>>> 
>>>> How does your release process work? What we've always
>>>> done is make the req changes to the branch and then copy
>>>> from that branch to the tag. So the tag itself must refer to
>>>> a specific SVN number on the http-2.4 branch but I'm
>>>> not seeing where that is done.
>>>> 
>>>> 
>>>> On Feb 19, 2018, at 9:54 AM, mailto:drugg...@primary.net wrote:
>>>> 
>>>> Hi, all;
>>>>  Please find below the proposed release tarball and signatures:
>>>> https://dist.apache.org/repos/dist/dev/httpd/
>>>> 
>>>> I would like to call a VOTE over the next few days to release this 
>>>> candidate
>> tarball as 2.4.30:
>>>> 
>>>> [ ] +1: It’s not just good, it’s good enough!
>>>> [ ] +0: Let’s have a talk…
>>>> [ ] -1: There’s trouble in paradise. Here’s what’s wrong.
>>>> --
>>>> Daniel Ruggeri
>>>> 
>>>> 
> 
> -- 
> Daniel Ruggeri

RE: [VOTE] Release httpd-2.4.30

[DRuggeri]

> -Original Message-
> From: Jim Jagielski [mailto:j...@jagunet.com]
> Sent: Tuesday, February 20, 2018 6:10 AM
> To: dev@httpd.apache.org
> Subject: Re: [VOTE] Release httpd-2.4.30
> 
> Another thing that helps is providing some heads-up
> that a T&R will actually be happening... Yeah, you
> had noted the you were going to T&R on Monday
> (in the "T&R of 2.4.30 Proposal" thread) but sending
> out a quick "I plan on doing this in X hours" notice
> allows for some possible last-minute items to pop
> up.
> 
> Just a suggestion.

Sure, I can do that.


> 
> > On Feb 19, 2018, at 9:44 PM, Jim Jagielski  wrote:
> >
> > I would suggest using the scripts from
> >
> > https://svn.apache.org/repos/asf/httpd/site/trunk/tools
> >
> > for as much of the work as possible since they have been used
> > and vetted for several years.

Indeed, I did for everything except the tagging (which is why I created a 
script to do it). I also created one to push to dev/release dist repos for 
convenience. As mentioned, the goal is to automate the process as much as 
possible so with the gap in existing tooling, I went ahead and filled it. I 
guess I just misinterpreted the instructions and didn’t think to review SVN 
history of the previous releases as Joe mentioned.

Aside from this omission, are we otherwise in good shape?


> >
> >> On Feb 19, 2018, at 7:28 PM, drugg...@primary.net wrote:
> >>
> >> Ah, I see. I created a script that does the tagging based on the directions
> here.
> >> http://httpd.apache.org/dev/release.html
> >>
> >> It was unclear in those instructions that one should commit the change to
> AP_SERVER_DEVBUILD_BOOLEAN.
> >>
> >> Instead I did the following:
> >> ...
> >> #Set AP_SERVER_DEVBUILD_BOOLEAN to 0 in include/ap_release.h.
> >> perl -pi -e 's/(#define\s+AP_SERVER_DEVBUILD_BOOLEAN\s+)\d/${1}0/g'
> include/ap_release.h
> >>
> >> #Create an official X.Y.Z tag based on the candidate tree.
> >> svn copy "$src_dir" "$tags_dir/$version"
> >>
> >> #Revert the change to include/ap_release.h setting
> AP_SERVER_DEVBUILD_BOOLEAN back to 1, and bump
> AP_SERVER_PATCHLEVEL_NUMBER
> >> perl -pi -e '
> >>  s/(#define\s+AP_SERVER_DEVBUILD_BOOLEAN\s+)\d/${1}1/g;
> >>
> >>  if(/(#define\s+AP_SERVER_PATCHLEVEL_NUMBER\s+)(\d+)$/){
> >>$new = $2 + 1;
> >>$_ = "${1}${new}\n";
> >>  }
> >>  ' include/ap_release.h
> >> ...
> >>
> >> This begets a tarball that has the Boolean set to 0, but no
> commit/revert/bump (instead just an apparent bump):
> >>
> http://svn.apache.org/viewvc/httpd/httpd/tags/2.4.30/include/ap_release.
> h?view=markup#l47
> >>
> >> It makes sense that the tag comes from a specific commit where the
> variable was flipped...  Should I adjust the script and retry?
> >>
> >> --
> >> Daniel Ruggeri
> >>
> >> From: Jim Jagielski [mailto:j...@jagunet.com]
> >> Sent: Monday, February 19, 2018 9:46 AM
> >> To: dev@httpd.apache.org
> >> Subject: Re: [VOTE] Release httpd-2.4.30
> >>
> >> Hmmm... I'm not seeing the patch where
> AP_SERVER_DEVBUILD_BOOLEAN
> >> in ap_release.h is set to 0
> >>
> >> How does your release process work? What we've always
> >> done is make the req changes to the branch and then copy
> >> from that branch to the tag. So the tag itself must refer to
> >> a specific SVN number on the http-2.4 branch but I'm
> >> not seeing where that is done.
> >>
> >>
> >> On Feb 19, 2018, at 9:54 AM, mailto:drugg...@primary.net wrote:
> >>
> >> Hi, all;
> >>   Please find below the proposed release tarball and signatures:
> >> https://dist.apache.org/repos/dist/dev/httpd/
> >>
> >> I would like to call a VOTE over the next few days to release this 
> >> candidate
> tarball as 2.4.30:
> >>
> >> [ ] +1: It’s not just good, it’s good enough!
> >> [ ] +0: Let’s have a talk…
> >> [ ] -1: There’s trouble in paradise. Here’s what’s wrong.
> >> --
> >> Daniel Ruggeri
> >>
> >>

-- 
Daniel Ruggeri

Re: [VOTE] Release httpd-2.4.30

[Jim Jagielski]

Another thing that helps is providing some heads-up
that a T&R will actually be happening... Yeah, you
had noted the you were going to T&R on Monday
(in the "T&R of 2.4.30 Proposal" thread) but sending
out a quick "I plan on doing this in X hours" notice
allows for some possible last-minute items to pop
up.

Just a suggestion.

> On Feb 19, 2018, at 9:44 PM, Jim Jagielski  wrote:
> 
> I would suggest using the scripts from
> 
> https://svn.apache.org/repos/asf/httpd/site/trunk/tools
> 
> for as much of the work as possible since they have been used
> and vetted for several years.
> 
>> On Feb 19, 2018, at 7:28 PM, drugg...@primary.net wrote:
>> 
>> Ah, I see. I created a script that does the tagging based on the directions 
>> here.
>> http://httpd.apache.org/dev/release.html
>> 
>> It was unclear in those instructions that one should commit the change to 
>> AP_SERVER_DEVBUILD_BOOLEAN.
>> 
>> Instead I did the following:
>> ...
>> #Set AP_SERVER_DEVBUILD_BOOLEAN to 0 in include/ap_release.h.
>> perl -pi -e 's/(#define\s+AP_SERVER_DEVBUILD_BOOLEAN\s+)\d/${1}0/g' 
>> include/ap_release.h
>> 
>> #Create an official X.Y.Z tag based on the candidate tree.
>> svn copy "$src_dir" "$tags_dir/$version"
>> 
>> #Revert the change to include/ap_release.h setting 
>> AP_SERVER_DEVBUILD_BOOLEAN back to 1, and bump AP_SERVER_PATCHLEVEL_NUMBER
>> perl -pi -e '
>>  s/(#define\s+AP_SERVER_DEVBUILD_BOOLEAN\s+)\d/${1}1/g;
>> 
>>  if(/(#define\s+AP_SERVER_PATCHLEVEL_NUMBER\s+)(\d+)$/){
>>$new = $2 + 1;
>>$_ = "${1}${new}\n";
>>  }
>>  ' include/ap_release.h
>> ...
>> 
>> This begets a tarball that has the Boolean set to 0, but no 
>> commit/revert/bump (instead just an apparent bump):
>> http://svn.apache.org/viewvc/httpd/httpd/tags/2.4.30/include/ap_release.h?view=markup#l47
>> 
>> It makes sense that the tag comes from a specific commit where the variable 
>> was flipped...  Should I adjust the script and retry?
>> 
>> -- 
>> Daniel Ruggeri
>> 
>> From: Jim Jagielski [mailto:j...@jagunet.com] 
>> Sent: Monday, February 19, 2018 9:46 AM
>> To: dev@httpd.apache.org
>> Subject: Re: [VOTE] Release httpd-2.4.30
>> 
>> Hmmm... I'm not seeing the patch where AP_SERVER_DEVBUILD_BOOLEAN
>> in ap_release.h is set to 0
>> 
>> How does your release process work? What we've always
>> done is make the req changes to the branch and then copy
>> from that branch to the tag. So the tag itself must refer to
>> a specific SVN number on the http-2.4 branch but I'm
>> not seeing where that is done.
>> 
>> 
>> On Feb 19, 2018, at 9:54 AM, mailto:drugg...@primary.net wrote:
>> 
>> Hi, all;
>>   Please find below the proposed release tarball and signatures:
>> https://dist.apache.org/repos/dist/dev/httpd/
>> 
>> I would like to call a VOTE over the next few days to release this candidate 
>> tarball as 2.4.30:
>> 
>> [ ] +1: It’s not just good, it’s good enough!
>> [ ] +0: Let’s have a talk…
>> [ ] -1: There’s trouble in paradise. Here’s what’s wrong.
>> -- 
>> Daniel Ruggeri
>> 
>> 
> 

Re: [VOTE] Release httpd-2.4.30

[Jim Jagielski]

-1: I think with the release process hiccups and the Win issues
noted in the "Current branche 2.4.30-dev issues" thread,
we will need a 2.4.31. Additionally, there are some
backports in STATUS that could also be folded in.

> On Feb 19, 2018, at 9:54 AM, drugg...@primary.net wrote:
> 
> Hi, all;
>Please find below the proposed release tarball and signatures:
> https://dist.apache.org/repos/dist/dev/httpd/
>  
> I would like to call a VOTE over the next few days to release this candidate 
> tarball as 2.4.30:
>  
> [ ] +1: It’s not just good, it’s good enough!
> [ ] +0: Let’s have a talk…
> [ ] -1: There’s trouble in paradise. Here’s what’s wrong.
> -- 
> Daniel Ruggeri

Re: [VOTE] Release httpd-2.4.30

[Jim Jagielski]

I would suggest using the scripts from

https://svn.apache.org/repos/asf/httpd/site/trunk/tools 
<https://svn.apache.org/repos/asf/httpd/site/trunk/tools>

for as much of the work as possible since they have been used
and vetted for several years.

> On Feb 19, 2018, at 7:28 PM, drugg...@primary.net wrote:
> 
> Ah, I see. I created a script that does the tagging based on the directions 
> here.
> http://httpd.apache.org/dev/release.html
> 
> It was unclear in those instructions that one should commit the change to 
> AP_SERVER_DEVBUILD_BOOLEAN.
> 
> Instead I did the following:
> ...
> #Set AP_SERVER_DEVBUILD_BOOLEAN to 0 in include/ap_release.h.
> perl -pi -e 's/(#define\s+AP_SERVER_DEVBUILD_BOOLEAN\s+)\d/${1}0/g' 
> include/ap_release.h
> 
> #Create an official X.Y.Z tag based on the candidate tree.
> svn copy "$src_dir" "$tags_dir/$version"
> 
> #Revert the change to include/ap_release.h setting 
> AP_SERVER_DEVBUILD_BOOLEAN back to 1, and bump AP_SERVER_PATCHLEVEL_NUMBER
> perl -pi -e '
>  s/(#define\s+AP_SERVER_DEVBUILD_BOOLEAN\s+)\d/${1}1/g;
> 
>  if(/(#define\s+AP_SERVER_PATCHLEVEL_NUMBER\s+)(\d+)$/){
>$new = $2 + 1;
>$_ = "${1}${new}\n";
>  }
>  ' include/ap_release.h
> ...
> 
> This begets a tarball that has the Boolean set to 0, but no 
> commit/revert/bump (instead just an apparent bump):
> http://svn.apache.org/viewvc/httpd/httpd/tags/2.4.30/include/ap_release.h?view=markup#l47
> 
> It makes sense that the tag comes from a specific commit where the variable 
> was flipped...  Should I adjust the script and retry?
> 
> -- 
> Daniel Ruggeri
> 
> From: Jim Jagielski [mailto:j...@jagunet.com] 
> Sent: Monday, February 19, 2018 9:46 AM
> To: dev@httpd.apache.org
> Subject: Re: [VOTE] Release httpd-2.4.30
> 
> Hmmm... I'm not seeing the patch where AP_SERVER_DEVBUILD_BOOLEAN
> in ap_release.h is set to 0
> 
> How does your release process work? What we've always
> done is make the req changes to the branch and then copy
> from that branch to the tag. So the tag itself must refer to
> a specific SVN number on the http-2.4 branch but I'm
> not seeing where that is done.
> 
> 
> On Feb 19, 2018, at 9:54 AM, mailto:drugg...@primary.net wrote:
> 
> Hi, all;
>   Please find below the proposed release tarball and signatures:
> https://dist.apache.org/repos/dist/dev/httpd/
> 
> I would like to call a VOTE over the next few days to release this candidate 
> tarball as 2.4.30:
> 
> [ ] +1: It’s not just good, it’s good enough!
> [ ] +0: Let’s have a talk…
> [ ] -1: There’s trouble in paradise. Here’s what’s wrong.
> -- 
> Daniel Ruggeri
> 
> 

RE: [VOTE] Release httpd-2.4.30

[DRuggeri]

Ah, I see. I created a script that does the tagging based on the directions 
here.
http://httpd.apache.org/dev/release.html

It was unclear in those instructions that one should commit the change to 
AP_SERVER_DEVBUILD_BOOLEAN.

Instead I did the following:
...
#Set AP_SERVER_DEVBUILD_BOOLEAN to 0 in include/ap_release.h.
perl -pi -e 's/(#define\s+AP_SERVER_DEVBUILD_BOOLEAN\s+)\d/${1}0/g' 
include/ap_release.h

#Create an official X.Y.Z tag based on the candidate tree.
svn copy "$src_dir" "$tags_dir/$version"

#Revert the change to include/ap_release.h setting 
AP_SERVER_DEVBUILD_BOOLEAN back to 1, and bump AP_SERVER_PATCHLEVEL_NUMBER
perl -pi -e '
  s/(#define\s+AP_SERVER_DEVBUILD_BOOLEAN\s+)\d/${1}1/g;

  if(/(#define\s+AP_SERVER_PATCHLEVEL_NUMBER\s+)(\d+)$/){
$new = $2 + 1;
$_ = "${1}${new}\n";
  }
  ' include/ap_release.h
...

This begets a tarball that has the Boolean set to 0, but no commit/revert/bump 
(instead just an apparent bump):
http://svn.apache.org/viewvc/httpd/httpd/tags/2.4.30/include/ap_release.h?view=markup#l47

It makes sense that the tag comes from a specific commit where the variable was 
flipped...  Should I adjust the script and retry?

-- 
Daniel Ruggeri

From: Jim Jagielski [mailto:j...@jagunet.com] 
Sent: Monday, February 19, 2018 9:46 AM
To: dev@httpd.apache.org
Subject: Re: [VOTE] Release httpd-2.4.30

Hmmm... I'm not seeing the patch where AP_SERVER_DEVBUILD_BOOLEAN
in ap_release.h is set to 0

How does your release process work? What we've always
done is make the req changes to the branch and then copy
from that branch to the tag. So the tag itself must refer to
a specific SVN number on the http-2.4 branch but I'm
not seeing where that is done.


On Feb 19, 2018, at 9:54 AM, mailto:drugg...@primary.net wrote:

Hi, all;
   Please find below the proposed release tarball and signatures:
https://dist.apache.org/repos/dist/dev/httpd/
 
I would like to call a VOTE over the next few days to release this candidate 
tarball as 2.4.30:
 
[ ] +1: It’s not just good, it’s good enough!
[ ] +0: Let’s have a talk…
[ ] -1: There’s trouble in paradise. Here’s what’s wrong.
-- 
Daniel Ruggeri

Re: [VOTE] Release httpd-2.4.30

[Jim Jagielski]

> On Feb 19, 2018, at 10:47 AM, Graham Leggett  wrote:
> 
> On 19 Feb 2018, at 5:45 PM, Jim Jagielski  > wrote:
> 
>> Hmmm... I'm not seeing the patch where AP_SERVER_DEVBUILD_BOOLEAN
>> in ap_release.h is set to 0
>> 
>> How does your release process work? What we've always
>> done is make the req changes to the branch and then copy
>> from that branch to the tag. So the tag itself must refer to
>> a specific SVN number on the http-2.4 branch but I'm
>> not seeing where that is done.
> 
> What I've done in the past is follow the commits for previous releases, using 
> them as a template for the steps to take.
> 

+1

Re: [VOTE] Release httpd-2.4.30

[Graham Leggett]

On 19 Feb 2018, at 5:45 PM, Jim Jagielski  wrote:

> Hmmm... I'm not seeing the patch where AP_SERVER_DEVBUILD_BOOLEAN
> in ap_release.h is set to 0
> 
> How does your release process work? What we've always
> done is make the req changes to the branch and then copy
> from that branch to the tag. So the tag itself must refer to
> a specific SVN number on the http-2.4 branch but I'm
> not seeing where that is done.

What I've done in the past is follow the commits for previous releases, using 
them as a template for the steps to take.

Regards,
Graham
—



smime.p7s
Description: S/MIME cryptographic signature

Re: [VOTE] Release httpd-2.4.30

[Jim Jagielski]

Hmmm... I'm not seeing the patch where AP_SERVER_DEVBUILD_BOOLEAN
in ap_release.h is set to 0

How does your release process work? What we've always
done is make the req changes to the branch and then copy
from that branch to the tag. So the tag itself must refer to
a specific SVN number on the http-2.4 branch but I'm
not seeing where that is done.

> On Feb 19, 2018, at 9:54 AM, drugg...@primary.net wrote:
> 
> Hi, all;
>Please find below the proposed release tarball and signatures:
> https://dist.apache.org/repos/dist/dev/httpd/ 
> 
>  
> I would like to call a VOTE over the next few days to release this candidate 
> tarball as 2.4.30:
>  
> [ ] +1: It’s not just good, it’s good enough!
> [ ] +0: Let’s have a talk…
> [ ] -1: There’s trouble in paradise. Here’s what’s wrong.
> -- 
> Daniel Ruggeri

Re: [VOTE] Release httpd-2.4.30

[Stefan Eissing]

> Am 19.02.2018 um 15:54 schrieb  :
> 
> Hi, all;
>Please find below the proposed release tarball and signatures:
> https://dist.apache.org/repos/dist/dev/httpd/
>  
> I would like to call a VOTE over the next few days to release this candidate 
> tarball as 2.4.30:
>  
> [ ] +1: It’s not just good, it’s good enough!
> [ ] +0: Let’s have a talk…
> [ ] -1: There’s trouble in paradise. Here’s what’s wrong.
> -- 
> Daniel Ruggeri

+1 

Tested: 17.4.0 Darwin (High Sierra 10.13.3), event+worker, http2 und md

Thanks for RMing, Daniel!