Re: svn commit: r1817381 - in /httpd/httpd/trunk: CHANGES docs/manual/mod/mod_ssl.xml docs/manual/sections.xml modules/ssl/mod_ssl.c modules/ssl/ssl_engine_config.c modules/ssl/ssl_policies.h modules/

[Ruediger Pluem]

On 12/07/2017 04:11 PM, ic...@apache.org wrote:
> Author: icing
> Date: Thu Dec  7 15:11:13 2017
> New Revision: 1817381
> 
> URL: http://svn.apache.org/viewvc?rev=1817381=rev
> Log:
> On the trunk:
> 
> mod_ssl: renamed section   for new server config merge flag. Denying global, only once used 
> directives
>  inside a SSLPolicyDefine.
> 
> 
> Modified:
> httpd/httpd/trunk/CHANGES
> httpd/httpd/trunk/docs/manual/mod/mod_ssl.xml
> httpd/httpd/trunk/docs/manual/sections.xml
> httpd/httpd/trunk/modules/ssl/mod_ssl.c
> httpd/httpd/trunk/modules/ssl/ssl_engine_config.c
> httpd/httpd/trunk/modules/ssl/ssl_policies.h
> httpd/httpd/trunk/modules/ssl/update_policies.py
> 

> Modified: httpd/httpd/trunk/modules/ssl/ssl_engine_config.c
> URL: 
> http://svn.apache.org/viewvc/httpd/httpd/trunk/modules/ssl/ssl_engine_config.c?rev=1817381=1817380=1817381=diff
> ==
> --- httpd/httpd/trunk/modules/ssl/ssl_engine_config.c (original)
> +++ httpd/httpd/trunk/modules/ssl/ssl_engine_config.c Thu Dec  7 15:11:13 2017
> @@ -93,7 +93,7 @@ void ssl_config_global_fix(SSLModConfigR
>  
>  BOOL ssl_config_global_isfixed(SSLModConfigRec *mc)
>  {
> -return mc->bFixed;
> +return mc && mc->bFixed;
>  }
>  
>  /*  _
> @@ -635,7 +635,7 @@ static apr_array_header_t *get_policy_na
>  
>  SSLPolicyRec *ssl_policy_lookup(apr_pool_t *pool, const char *name)
>  {
> -apr_hash_t *policies = get_policies(pool, 0);
> +apr_hash_t *policies = get_policies(pool, 1);
>  if (policies) {
>  return apr_hash_get(policies, name, APR_HASH_KEY_STRING);
>  }

Hm, the else case below the lines above does not seem to be needed any longer, 
since policies should not be NULL, correct?

Regards

Rüdiger

Re: mod_md and ManagedDomain

[Jim Jagielski]

> On Dec 11, 2017, at 9:09 AM, Steffen  wrote:
> 
> 
> A cause for minimal participation can be that dev is going with git. 
> 
> Mentioned Issues and Requests are at https://github.com/icing/mod_md/issues 
>  and not at a httpd  list. 
> 
> The renaming discussion  was one of the mod_md sporadic posts on the dev list 
> at a late moment. Do not feel kidding, I think the more you use this list the 
> more responses you get (only 22 are watching at git).
> 
> The windows community has tested/participated from the beginning. I do not 
> know how much is tested  on other platforms by users.
> 
> From now on I prefer to discuss issues/requests here at this list. And I like 
> to see test reports from non-windows platforms.
> 
> @Jim In status I see you voted +1, is that based on code review and/or 
> testing ?

Yes, both :)

> 
> 
> 
>  
> On Monday 11/12/2017 at 11:11, Stefan Eissing wrote:
>> 
>> 
>>> Am 11.12.2017 um 11:08 schrieb Stefan Eissing >> >:
>>> 
>>> 
 Am 08.12.2017 um 19:35 schrieb William A Rowe Jr >:
 
 On Tue, Dec 5, 2017 at 8:03 AM, Luca Toscano > wrote:
> Maybe ManagedDomain and , as iiuc we are going to use
> for SSLPolicy?
 
 Just an observation, 
 http://httpd.apache.org/docs/trunk/mod/quickreference.html 
 
 illustrated that we have no verbs in  directive block
 titles, thus far.
 
  or  followed by ManagedDomainSet
 or MDPolicyElect or something similar seems more in keeping with the
 existing naming convention for directives. Bothers me when we overload
 with yet one additional naming scheme, that would probably bother our
 users more than confusing directive names.
>>> 
>>> There are important questions on how we progress the design of the server. 
>>> I 
>>> have asked for participation and feedback on the design of ACME support in 
>>> httpd
>>> since April. Shoulder clapping, "go ahead!", "fine!".
>>> 
>>> Answers to design questions: not really
>>> Requests for opinion about a "restart" feature: 0
>>> Code request for a Windows Service restart call: 0
>>> Request of a serf based implementation of the http client: 0
>>> Feedback from testing by the team: 0
>> 
>> Correction: Steffen and Luca have tested and given feedback.
>> 
>>> Opinions about renaming parts/the whole thing just days before
>>> a possible release to users who want this: +7
>>> 
>>> You got to be kiddding me!
>>> 
>>> Cheers,
>>> 
>>> Stefan
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>> 
> 
> 

mod_md 1.1.0 repeating on error

[Steffen]

Running 1.1.0 with the new naming.

When mod_md encounters an error it looks like it is going in a endless 
loop:



[md:info] [pid 10372:tid 1964] AH10057: apachelounge.nl: encountered 
error for the 1. time, next run in  0:00:05 hours
[md:info] [pid 10372:tid 1964] AH10057: apachelounge.nl: encountered 
error for the 2. time, next run in  0:00:10 hours
[md:info] [pid 10372:tid 1964] AH10057: apachelounge.nl: encountered 
error for the 3. time, next run in  0:00:20 hours
[md:info] [pid 10372:tid 1964] AH10057: apachelounge.nl: encountered 
error for the 4. time, next run in  0:00:40 hours
[md:info] [pid 10372:tid 1964] AH10057: apachelounge.nl: encountered 
error for the 5. time, next run in  0:01:20 hours
[md:info] [pid 10372:tid 1964] AH10057: apachelounge.nl: encountered 
error for the 6. time, next run in  0:02:40 hours
[md:info] [pid 10372:tid 1964] AH10057: apachelounge.nl: encountered 
error for the 7. time, next run in  0:05:20 hours
[md:info] [pid 10372:tid 1964] AH10057: apachelounge.nl: encountered 
error for the 8. time, next run in  0:10:40 hours

...
...
...

Above is during renew and using port 444..

Apache is running fine  because the certificate is still valid.

Does it stop ?

When does it happen,  on what errors ? Above happens when: 
(20014)Internal error (specific information not available): AH10056: 
processing apachelounge.nl.


What to do.  Stopping on above retries can be tricky because when the 
ACME CA service is temp down or not reachable we do want maybe a 
retry.  A reachable error/down error is different then a configuration 
error causing it like in above case..

Re: mod_md and ManagedDomain

[Rich Bowen]

On 12/11/2017 05:08 AM, Stefan Eissing wrote:

There are important questions on how we progress the design of the server. I
have asked for participation and feedback on the design of ACME support in httpd
since April. Shoulder clapping, "go ahead!", "fine!".

Answers to design questions: not really
Requests for opinion about a "restart" feature: 0
Code request for a Windows Service restart call: 0
Request of a serf based implementation of the http client: 0
Feedback from testing by the team: 0

Opinions about renaming parts/the whole thing just days before
a possible release to users who want this: +7

You got to be kiddding me!


My apologies. I have no insight or skills in those other areas. My sole 
area of expertise is documentation and the users that use those 
documents. As I said before, please feel free to ignore my input and 
move on. Sorry I brought it up.

Re: mod_md and ManagedDomain

[William A Rowe Jr]

On Dec 11, 2017 08:55, "Stefan Eissing" .


Documentation update is still outstanding, but I assume merging those in is
not really a voting issue.


Docs are CTR. Might be an issue for some to introduce undocumented changes
in the maintenance branch, but is easily remedied.

Re: [VOTE] Release httpd 2.5.0-alpha

[William A Rowe Jr]

On Nov 25, 2017 09:13, "Daniel Ruggeri"  wrote:


As a side note, I'm experimenting with ways to capture build and test
output as well as relevant system info related to a tested version of
httpd. Here's the current format I am using in YML (can be seen here for
this build: http://people.apache.org/~druggeri/tmp/latest_sources.yml)
httpd:
  vote:
  version_info:
  configure:
  build:
result:
log:
  test:
result:
log:
system:
  kernel:
name:
release:
version:
machine:
  libraries:
libxyz:

Feedback on anything else I should be capturing is welcome. This is the
only surviving artifact of the build and test since it's all done in
ephemeral docker containers.


Thanks for leaving this open a couple more days. I'll pull a parallel
package and diff my expectations against the tarball.  Will also have an
initial vote on the resulting build by Wed.

Re: mod_md and ManagedDomain

[Stefan Eissing]

The following change has been made to trunk:

- mod_md v1.1.0 with renamed configuration directives:
  "ManagedDomain" -> "MDomain"
  " " Am 11.12.2017 um 15:09 schrieb Steffen :
> 
> 
> A cause for minimal participation can be that dev is going with git. 
> 
> Mentioned Issues and Requests are at https://github.com/icing/mod_md/issues 
> and not at a httpd  list. 
> 
> The renaming discussion  was one of the mod_md sporadic posts on the dev list 
> at a late moment. Do not feel kidding, I think the more you use this list the 
> more responses you get (only 22 are watching at git).
> 
> The windows community has tested/participated from the beginning. I do not 
> know how much is tested  on other platforms by users.
> 
> From now on I prefer to discuss issues/requests here at this list. And I like 
> to see test reports from non-windows platforms.
> 
> @Jim In status I see you voted +1, is that based on code review and/or 
> testing ?
> 
> 
> 
>  
> On Monday 11/12/2017 at 11:11, Stefan Eissing wrote:
>> 
>> 
>>> Am 11.12.2017 um 11:08 schrieb Stefan Eissing 
>>> :
>>> 
>>> 
 Am 08.12.2017 um 19:35 schrieb William A Rowe Jr :
 
 On Tue, Dec 5, 2017 at 8:03 AM, Luca Toscano  
 wrote:
> Maybe ManagedDomain and , as iiuc we are going to use
> for SSLPolicy?
 
 Just an observation, 
 http://httpd.apache.org/docs/trunk/mod/quickreference.html
 illustrated that we have no verbs in  directive block
 titles, thus far.
 
  or  followed by ManagedDomainSet
 or MDPolicyElect or something similar seems more in keeping with the
 existing naming convention for directives. Bothers me when we overload
 with yet one additional naming scheme, that would probably bother our
 users more than confusing directive names.
>>> 
>>> There are important questions on how we progress the design of the server. 
>>> I 
>>> have asked for participation and feedback on the design of ACME support in 
>>> httpd
>>> since April. Shoulder clapping, "go ahead!", "fine!".
>>> 
>>> Answers to design questions: not really
>>> Requests for opinion about a "restart" feature: 0
>>> Code request for a Windows Service restart call: 0
>>> Request of a serf based implementation of the http client: 0
>>> Feedback from testing by the team: 0
>> 
>> Correction: Steffen and Luca have tested and given feedback.
>> 
>>> Opinions about renaming parts/the whole thing just days before
>>> a possible release to users who want this: +7
>>> 
>>> You got to be kiddding me!
>>> 
>>> Cheers,
>>> 
>>> Stefan
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>> 
> 
> 

Re: mod_md and ManagedDomain

[Steffen]

A cause for minimal participation can be that dev is going with git.

Mentioned Issues and Requests are at 
https://github.com/icing/mod_md/issues and not at a httpd  list.


The renaming discussion  was one of the mod_md sporadic posts on the 
dev list at a late moment. Do not feel kidding, I think the more you 
use this list the more responses you get (only 22 are watching at 
git).


The windows community has tested/participated from the beginning. I do 
not know how much is tested  on other platforms by users.



From now on I prefer to discuss issues/requests here at this list. And 

I like to see test reports from non-windows platforms.


@Jim In status I see you voted +1, is that based on code review and/or 
testing ?









On Monday 11/12/2017 at 11:11, Stefan Eissing  wrote:





Am 11.12.2017 um 11:08 schrieb Stefan Eissing 
:





Am 08.12.2017 um 19:35 schrieb William A Rowe Jr 
:


On Tue, Dec 5, 2017 at 8:03 AM, Luca Toscano  
wrote:


Maybe ManagedDomain and , as iiuc we are going to 
use

for SSLPolicy?


Just an observation, 
http://httpd.apache.org/docs/trunk/mod/quickreference.html

illustrated that we have no verbs in  directive block
titles, thus far.

 or  followed by ManagedDomainSet
or MDPolicyElect or something similar seems more in keeping with the
existing naming convention for directives. Bothers me when we overload
with yet one additional naming scheme, that would probably bother our
users more than confusing directive names.


There are important questions on how we progress the design of the 
server. I
have asked for participation and feedback on the design of ACME 
support in httpd

since April. Shoulder clapping, "go ahead!", "fine!".

Answers to design questions: not really
Requests for opinion about a "restart" feature: 0
Code request for a Windows Service restart call: 0
Request of a serf based implementation of the http client: 0
Feedback from testing by the team: 0


Correction: Steffen and Luca have tested and given feedback.



Opinions about renaming parts/the whole thing just days before
a possible release to users who want this: +7

You got to be kiddding me!

Cheers,

Stefan

Re: mod_md and ManagedDomain

[Jim Jagielski]

I am a SUPER +1 on the design, architecture, etc...

As far as the naming, it seems like a bikeshed to me...
JFDI ;)

> On Dec 11, 2017, at 5:08 AM, Stefan Eissing  
> wrote:
> 
> 
>> Am 08.12.2017 um 19:35 schrieb William A Rowe Jr :
>> 
>> On Tue, Dec 5, 2017 at 8:03 AM, Luca Toscano  wrote:
>>> Maybe ManagedDomain and , as iiuc we are going to use
>>> for SSLPolicy?
>> 
>> Just an observation, 
>> http://httpd.apache.org/docs/trunk/mod/quickreference.html
>> illustrated that we have no verbs in  directive block
>> titles, thus far.
>> 
>>  or  followed by ManagedDomainSet
>> or MDPolicyElect or something similar seems more in keeping with the
>> existing naming convention for directives. Bothers me when we overload
>> with yet one additional naming scheme, that would probably bother our
>> users more than confusing directive names.
> 
> There are important questions on how we progress the design of the server. I 
> have asked for participation and feedback on the design of ACME support in 
> httpd
> since April. Shoulder clapping, "go ahead!", "fine!".
> 
> Answers to design questions: not really
> Requests for opinion about a "restart" feature: 0
> Code request for a Windows Service restart call: 0
> Request of a serf based implementation of the http client: 0
> Feedback from testing by the team: 0
> 
> Opinions about renaming parts/the whole thing just days before
> a possible release to users who want this: +7
> 
> You got to be kiddding me!
> 
> Cheers,
> 
> Stefan
> 
> 
> 
> 
> 
> 

Re: [VOTE] Release httpd 2.5.0-alpha

[Jacob Perkins]

Morning,

As a FYI on this, we got it built under our platforms and had no immediate, 
glaring issues. We didn’t do our full fledged tests as we have to do a lot more 
work to support our 2.5 version of templates and such. 

I hope this helps! 

—
Jacob Perkins
Product Owner
cPanel Inc.

jacob.perk...@cpanel.net 
Office:  713-529-0800 x 4046
Cell:  713-560-8655

> On Dec 11, 2017, at 3:42 AM, Stefan Eissing  
> wrote:
> 
> Daniel, I am very much interested in a smooth and more automated 
> release process. However, I am very unfamiliar regarding what is
> all involved and cannot judge if it is complete. You'd probably
> want Jim's input on this.
> 
> Cheers,
> Stefan
> 
>> Am 09.12.2017 um 21:05 schrieb Daniel Ruggeri :
>> 
>> With about a month of time the vote has been running and just a single
>> +1 (my own), I'm of the opinion that this release has died on the vine.
>> I am sensitive to the fact that this is the holiday season, so I will
>> keep it open only a few more days so folks can pipe up if they are still
>> testing or need more time to evaluate the release.
>> 
>> 
>> While it's OK and all if we don't push 2.5.0-alpha, I'm wondering if
>> anyone has been able to at least validate the structural stuff involving
>> the release? As in... Was the signature good? Did the release tarball
>> appear to be laid out as expected? Did the tags and source files show up
>> where/how we expect in trunk? Assuming that's all good, I'd like to
>> volunteer for 2.4.next... but I'd like confirmation.
>> 
>> 
>> I'm also acutely interested in those aspects because they are the result
>> of the machinery created to prepare the tags for a release and the first
>> time I've used the existing scripts per documentation. If an adjustment
>> (to the script I created, the existing scripts that are used, or the
>> documentation on how to roll a release) is needed, I'd like to
>> straighten that out now before moving forward with tying it all together
>> with an automated build plan.
>> 
>> -- 
>> Daniel Ruggeri
>> 
>> On 11/7/2017 8:36 PM, Daniel Ruggeri wrote:
>>> Hi, all;
>>> 
>>>   Please find the proposed 2.5.0-alpha release tarballs and signatures
>>> at the following location. This release candidate was tagged from trunk
>>> as of r1814469:
>>> 
>>> https://dist.apache.org/repos/dist/dev/httpd/
>>> 
>>> 
>>> I'd like to call a vote to release this alpha candidate. Please do note
>>> - this is my first attempt at cutting a release and mistakes are likely.
>>> Therefore, I'll let the vote run at least 10 days (possibly more as I
>>> will be traveling to Dublin next week) and will greatly appreciate any
>>> additional scrutiny the release tarball can be given.
>>> 
>>> 
>>> 
>>> Some notes to share after having executed the process for the first time:
>>> 
>>> * I'm not 100% sure on the proper syntax for an alpha candidate with the
>>> release.sh[1] script. I used "./release.sh --tag 2.5.0-alpha alpha
>>> httpd-2.5 2.5.0 'drugg...@primary.net". This seems to have produced
>>> desired results.
>>> 
>>> * I created two scripts[2] to automate the tagging of SVN and minor file
>>> modifications associated with a release as well as the push of the
>>> tarballs/signatures to the repo mirror. Unfortunately, I lack the karma
>>> to commit to site/trunk. How do I obtain this karma?
>>> 
>>> * I'd like to make some updates to the documentation[3] about how to
>>> produce releases to point out the existence of the new scripts and make
>>> the process more clear. Same note about karma to site/ applies.
>>> 
>>> * The documentation mentioned to AP_SERVER_DEVBUILD_BOOLEAN to 0 for the
>>> tagged release. I assume this still holds true for an alpha release.
>>> 
>>> * Blockers for automation really only seem to live around credential
>>> management (svn password and keyring passphrase) and the conducting of
>>> the vote itself over email. Kudos to everyone involved for putting
>>> together the scripting that already exists!
>>> 
>>> * I'd like to create yet another script that does a pre-flight check for
>>> a machine to ensure that the host it is run on has the dependencies all
>>> of the above scripts need. Thing is, other than java for the docs build
>>> and gpg... I'm not sure what those other things may be (or even if there
>>> are any). Pointers welcome.
>>> 
>>> 
>>> [1] http://svn.apache.org/repos/asf/httpd/site/trunk/tools/release.sh
>>> 
>>> [2] http://people.apache.org/~druggeri/scripts/
>>> 
>>> [3] http://httpd.apache.org/dev/release.html
>>> 
>>> 
>>> P.S.
>>> 
>>> I'll be in Dublin next week if anyone would like to catch up!
>>> 
>> 
> 

Re: mod_md and ManagedDomain

[Luca Toscano]

Hi Stefan,

2017-12-11 11:08 GMT+01:00 Stefan Eissing :

>
> > Am 08.12.2017 um 19:35 schrieb William A Rowe Jr :
> >
> > On Tue, Dec 5, 2017 at 8:03 AM, Luca Toscano 
> wrote:
> >> Maybe ManagedDomain and , as iiuc we are going to
> use
> >> for SSLPolicy?
> >
> > Just an observation, http://httpd.apache.org/docs/
> trunk/mod/quickreference.html
> > illustrated that we have no verbs in  directive block
> > titles, thus far.
> >
> >  or  followed by ManagedDomainSet
> > or MDPolicyElect or something similar seems more in keeping with the
> > existing naming convention for directives. Bothers me when we overload
> > with yet one additional naming scheme, that would probably bother our
> > users more than confusing directive names.
>
> There are important questions on how we progress the design of the server.
> I
> have asked for participation and feedback on the design of ACME support in
> httpd
> since April. Shoulder clapping, "go ahead!", "fine!".
>
> Answers to design questions: not really
> Requests for opinion about a "restart" feature: 0
> Code request for a Windows Service restart call: 0
> Request of a serf based implementation of the http client: 0
> Feedback from testing by the team: 0
>
> Opinions about renaming parts/the whole thing just days before
> a possible release to users who want this: +7
>
> You got to be kiddding me!
>

you are right but at the moment, since nobody have really different
opinions, the only thing that "blocks" the backport is the naming of the
ManagedDomain and  directives. As you suggested
s/ManagedDomain/MDGroup seems to be ok for most of us, the remaining one is
.  could be a solution, or any other similar
name.

Let's pick one, archive the thread and deliver a nice gift for the holiday
season to all the apache users :)

Thanks for the patience!

Luca

Re: mod_md and ManagedDomain

[Stefan Eissing]

> Am 11.12.2017 um 11:08 schrieb Stefan Eissing :
> 
> 
>> Am 08.12.2017 um 19:35 schrieb William A Rowe Jr :
>> 
>> On Tue, Dec 5, 2017 at 8:03 AM, Luca Toscano  wrote:
>>> Maybe ManagedDomain and , as iiuc we are going to use
>>> for SSLPolicy?
>> 
>> Just an observation, 
>> http://httpd.apache.org/docs/trunk/mod/quickreference.html
>> illustrated that we have no verbs in  directive block
>> titles, thus far.
>> 
>>  or  followed by ManagedDomainSet
>> or MDPolicyElect or something similar seems more in keeping with the
>> existing naming convention for directives. Bothers me when we overload
>> with yet one additional naming scheme, that would probably bother our
>> users more than confusing directive names.
> 
> There are important questions on how we progress the design of the server. I 
> have asked for participation and feedback on the design of ACME support in 
> httpd
> since April. Shoulder clapping, "go ahead!", "fine!".
> 
> Answers to design questions: not really
> Requests for opinion about a "restart" feature: 0
> Code request for a Windows Service restart call: 0
> Request of a serf based implementation of the http client: 0
> Feedback from testing by the team: 0

Correction: Steffen and Luca have tested and given feedback.

> Opinions about renaming parts/the whole thing just days before
> a possible release to users who want this: +7
> 
> You got to be kiddding me!
> 
> Cheers,
> 
> Stefan
> 
> 
> 
> 
> 
> 

Re: mod_md and ManagedDomain

[Stefan Eissing]

> Am 08.12.2017 um 19:35 schrieb William A Rowe Jr :
> 
> On Tue, Dec 5, 2017 at 8:03 AM, Luca Toscano  wrote:
>> Maybe ManagedDomain and , as iiuc we are going to use
>> for SSLPolicy?
> 
> Just an observation, 
> http://httpd.apache.org/docs/trunk/mod/quickreference.html
> illustrated that we have no verbs in  directive block
> titles, thus far.
> 
>  or  followed by ManagedDomainSet
> or MDPolicyElect or something similar seems more in keeping with the
> existing naming convention for directives. Bothers me when we overload
> with yet one additional naming scheme, that would probably bother our
> users more than confusing directive names.

There are important questions on how we progress the design of the server. I 
have asked for participation and feedback on the design of ACME support in httpd
since April. Shoulder clapping, "go ahead!", "fine!".

Answers to design questions: not really
Requests for opinion about a "restart" feature: 0
Code request for a Windows Service restart call: 0
Request of a serf based implementation of the http client: 0
Feedback from testing by the team: 0

Opinions about renaming parts/the whole thing just days before
a possible release to users who want this: +7

You got to be kiddding me!

Cheers,

Stefan

Re: [VOTE] Release httpd 2.5.0-alpha

[Stefan Eissing]

Daniel, I am very much interested in a smooth and more automated 
release process. However, I am very unfamiliar regarding what is
all involved and cannot judge if it is complete. You'd probably
want Jim's input on this.

Cheers,
Stefan

> Am 09.12.2017 um 21:05 schrieb Daniel Ruggeri :
> 
> With about a month of time the vote has been running and just a single
> +1 (my own), I'm of the opinion that this release has died on the vine.
> I am sensitive to the fact that this is the holiday season, so I will
> keep it open only a few more days so folks can pipe up if they are still
> testing or need more time to evaluate the release.
> 
> 
> While it's OK and all if we don't push 2.5.0-alpha, I'm wondering if
> anyone has been able to at least validate the structural stuff involving
> the release? As in... Was the signature good? Did the release tarball
> appear to be laid out as expected? Did the tags and source files show up
> where/how we expect in trunk? Assuming that's all good, I'd like to
> volunteer for 2.4.next... but I'd like confirmation.
> 
> 
> I'm also acutely interested in those aspects because they are the result
> of the machinery created to prepare the tags for a release and the first
> time I've used the existing scripts per documentation. If an adjustment
> (to the script I created, the existing scripts that are used, or the
> documentation on how to roll a release) is needed, I'd like to
> straighten that out now before moving forward with tying it all together
> with an automated build plan.
> 
> -- 
> Daniel Ruggeri
> 
> On 11/7/2017 8:36 PM, Daniel Ruggeri wrote:
>> Hi, all;
>> 
>>Please find the proposed 2.5.0-alpha release tarballs and signatures
>> at the following location. This release candidate was tagged from trunk
>> as of r1814469:
>> 
>> https://dist.apache.org/repos/dist/dev/httpd/
>> 
>> 
>> I'd like to call a vote to release this alpha candidate. Please do note
>> - this is my first attempt at cutting a release and mistakes are likely.
>> Therefore, I'll let the vote run at least 10 days (possibly more as I
>> will be traveling to Dublin next week) and will greatly appreciate any
>> additional scrutiny the release tarball can be given.
>> 
>> 
>> 
>> Some notes to share after having executed the process for the first time:
>> 
>> * I'm not 100% sure on the proper syntax for an alpha candidate with the
>> release.sh[1] script. I used "./release.sh --tag 2.5.0-alpha alpha
>> httpd-2.5 2.5.0 'drugg...@primary.net". This seems to have produced
>> desired results.
>> 
>> * I created two scripts[2] to automate the tagging of SVN and minor file
>> modifications associated with a release as well as the push of the
>> tarballs/signatures to the repo mirror. Unfortunately, I lack the karma
>> to commit to site/trunk. How do I obtain this karma?
>> 
>> * I'd like to make some updates to the documentation[3] about how to
>> produce releases to point out the existence of the new scripts and make
>> the process more clear. Same note about karma to site/ applies.
>> 
>> * The documentation mentioned to AP_SERVER_DEVBUILD_BOOLEAN to 0 for the
>> tagged release. I assume this still holds true for an alpha release.
>> 
>> * Blockers for automation really only seem to live around credential
>> management (svn password and keyring passphrase) and the conducting of
>> the vote itself over email. Kudos to everyone involved for putting
>> together the scripting that already exists!
>> 
>> * I'd like to create yet another script that does a pre-flight check for
>> a machine to ensure that the host it is run on has the dependencies all
>> of the above scripts need. Thing is, other than java for the docs build
>> and gpg... I'm not sure what those other things may be (or even if there
>> are any). Pointers welcome.
>> 
>> 
>> [1] http://svn.apache.org/repos/asf/httpd/site/trunk/tools/release.sh
>> 
>> [2] http://people.apache.org/~druggeri/scripts/
>> 
>> [3] http://httpd.apache.org/dev/release.html
>> 
>> 
>> P.S.
>> 
>> I'll be in Dublin next week if anyone would like to catch up!
>> 
>