Mailing List Archive

release?
It would be great if we could make a release this month. There are several fixes and improvements already backported and a few outstanding issues that need a vote or two.

Please have a look if you find the time. I think Daniel expressed willingness to RM this? That'd be great!

Cheers, Stefan
Re: release? [ In reply to ]
+1. If Daniel doesn't have the time, I can.

> On Jul 18, 2019, at 10:06 AM, Stefan Eissing <stefan.eissing@greenbytes.de> wrote:
>
> It would be great if we could make a release this month. There are several fixes and improvements already backported and a few outstanding issues that need a vote or two.
>
> Please have a look if you find the time. I think Daniel expressed willingness to RM this? That'd be great!
>
> Cheers, Stefan
Re: release? [ In reply to ]
> On Jul 19, 2019, at 7:41 AM, Daniel Ruggeri <DRuggeri@primary.net> wrote:
>
> Argh. I guess my mail client ate my response.
>
> I replied yesterday with a +1 and offered to begin the process Friday (a week from today).
>
> I am available for being RM since the heavy lifting is scripted, but if you would prefer to, it's all yours, Jim :-)
>

I wouldn't mind giving it a spin... might be a good way to get a wider UX on the scripting.

> Happy weekend!
> --
> Daniel Ruggeri
>
> On July 19, 2019 6:34:10 AM CDT, Jim Jagielski <jim@jaguNET.com> wrote:
> +1. If Daniel doesn't have the time, I can.
>
> On Jul 18, 2019, at 10:06 AM, Stefan Eissing <stefan.eissing@greenbytes.de> wrote:
>
> It would be great if we could make a release this month. There are several fixes and improvements already backported and a few outstanding issues that need a vote or two.
>
> Please have a look if you find the time. I think Daniel expressed willingness to RM this? That'd be great!
>
> Cheers, Stefan
>
Re: release? [ In reply to ]
Hi,

PR60757 and corresponding r1853560 could be a good candidate for backport.

I don't have a configuration for testing so I won't propose it myself
for backport, but the patch looks simple.

CJ

Le 18/07/2019 à 16:06, Stefan Eissing a écrit :
> It would be great if we could make a release this month. There are several fixes and improvements already backported and a few outstanding issues that need a vote or two.
>
> Please have a look if you find the time. I think Daniel expressed willingness to RM this? That'd be great!
>
> Cheers, Stefan
Re: release? [ In reply to ]
m 20.07.2019 um 10:38 schrieb Marion & Christophe JAILLET:
> Hi,
>
> PR60757 and corresponding r1853560 could be a good candidate for backport.
>
> I don't have a configuration for testing so I won't propose it myself
> for backport, but the patch looks simple.

I have added this one (mod_proxy_hcheck in BalancerMember) and two other
ones ("Mute frequent debug message in mod_proxy_hcheck" and "bytraffic
needs byrequests") to STATUS right now.

Regards,

Rainer

> Le 18/07/2019 à 16:06, Stefan Eissing a écrit :
>> It would be great if we could make a release this month. There are
>> several fixes and improvements already backported and a few
>> outstanding issues that need a vote or two.
>>
>> Please have a look if you find the time. I think Daniel expressed
>> willingness to RM this? That'd be great!
>>
>> Cheers, Stefan
RE: release? [ In reply to ]
Hi,

Is this release likely to be ready before August 10? I am guessing "no" at this point, but wanted to get an idea early.

Cheers,
Mark

-----Original Message-----
From: Rainer Jung [mailto:rainer.jung@kippdata.de]
Sent: 20 July 2019 10:44
To: dev@httpd.apache.org
Subject: Re: release?

m 20.07.2019 um 10:38 schrieb Marion & Christophe JAILLET:
> Hi,
>
> PR60757 and corresponding r1853560 could be a good candidate for backport.
>
> I don't have a configuration for testing so I won't propose it myself
> for backport, but the patch looks simple.

I have added this one (mod_proxy_hcheck in BalancerMember) and two other ones ("Mute frequent debug message in mod_proxy_hcheck" and "bytraffic needs byrequests") to STATUS right now.

Regards,

Rainer

> Le 18/07/2019 à 16:06, Stefan Eissing a écrit :
>> It would be great if we could make a release this month. There are
>> several fixes and improvements already backported and a few
>> outstanding issues that need a vote or two.
>>
>> Please have a look if you find the time. I think Daniel expressed
>> willingness to RM this? That'd be great!
>>
>> Cheers, Stefan


---
This e-mail may contain confidential and/or privileged information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and delete this e-mail. Any unauthorized copying, disclosure or distribution of the material in this e-mail is strictly forbidden.

Please refer to https://www.db.com/disclosures for additional EU corporate and regulatory disclosures and to http://www.db.com/unitedkingdom/content/privacy.htm for information about privacy.
Re: release? [ In reply to ]
> Is this release likely to be ready before August 10? I am guessing "no" at this point, but wanted to get an idea early.

Not likely
Re: release? [ In reply to ]
On Mon, Aug 30, 2021 at 1:54 PM Eric Covener <covener@gmail.com> wrote:
>
> Also: Anyone who has a showstopper to delay a release (even if not yet
> proposed) please add it to 2.4.x STATUS so we can get things in order.

I think that BZ 65519 and 65521 are showstoppers, I'm waiting for
feedbacks from the OP to commit to trunk and propose the backport, but
if it lasts too long I'll do it anyway..


Cheers;
Yann.
Re: release? [ In reply to ]
Le 30/08/2021 à 13:53, Eric Covener a écrit :
> On Mon, Aug 30, 2021 at 7:36 AM stefan@eissing.org <stefan@eissing.org> wrote:
>> In what state is our release handling? Given someone holding my hand, could I do it? Or is it better to look someone over the shoulder while he does it?
> If there is an over-the-shoulder session I would like to tag along. I
> am flexible on time of day but I am GMT+4 (EDT). I can host on webex.
> Otherwise if you just want to struggle through it I can tag along but
> I have no experience.

I can give another try with my limited experience.

I definitively would like to add a --dry-run option for all scripts so
that they can be run for learning purpose without the fear of
un-expected impact on svn.

Existing scripts are not that easy to read at first, but are
understanbdable and following
http://httpd.apache.org/dev/release.html#how-to-do-a-release helps a
lot. The scripts should also be tweaked because of the latest changes in
several places (at least web site update (now on github) and CVE
announcement (if any) now that part of the process is handled elsewhere).

The CVE announcement should be much easier, now that we have a "Send
these Emails" on cveprocess.a.o. This should simplify part of the
process where we were preparing some scripts to send the announcement
emails.

I've been lacking time for httpd since many weeks, but I should be able
to RM next week if needed.

CJ

> Also: Anyone who has a showstopper to delay a release (even if not yet
> proposed) please add it to 2.4.x STATUS so we can get things in order.
>
Re: release? [ In reply to ]
On 8/30/2021 3:53 PM, Christophe JAILLET wrote:
>
> Le 30/08/2021 à 13:53, Eric Covener a écrit :
>> On Mon, Aug 30, 2021 at 7:36 AM stefan@eissing.org
>> <stefan@eissing.org> wrote:
>>> In what state is our release handling? Given someone holding my
>>> hand, could I do it? Or is it better to look someone over the
>>> shoulder while he does it?
>> If there is an over-the-shoulder session I would like to tag along.  I
>> am flexible on time of day but I am GMT+4 (EDT).  I can host on webex.
>> Otherwise if you just want to struggle through it I can tag along but
>> I have no experience.
>
> I can give another try with my limited experience.
>
> I definitively would like to add a --dry-run option for all scripts so
> that they can be run for learning purpose without the fear of
> un-expected impact on svn.

FWIW, the announce.sh script which collates all the security "stuff" and
sends the announce emails drops the user to a shell to inspect/examine
what WILL happen before actually doing anything. Any non-zero return
code of that shell will abort the process. I used the heck out of that
several times :-)


>
> Existing scripts are not that easy to read at first, but are
> understanbdable and following
> http://httpd.apache.org/dev/release.html#how-to-do-a-release helps a
> lot. The scripts should also be tweaked because of the latest changes
> in several places (at least web site update (now on github) and CVE
> announcement (if any) now that part of the process is handled elsewhere).
>

+1

To my knowledge, the publishing of the site and overhaul of the new CVE
process are the things requiring updates.

--
Daniel Ruggeri

> The CVE announcement should be much easier, now that we have a "Send
> these Emails" on cveprocess.a.o. This should simplify part of the
> process where we were preparing some scripts to send the announcement
> emails.
>
> I've been lacking time for httpd since many weeks, but I should be
> able to RM next week if needed.
>
> CJ
>
>> Also: Anyone who has a showstopper to delay a release (even if not yet
>> proposed) please add it to 2.4.x STATUS so we can get things in order.
>>
Re: release? [ In reply to ]
> Am 30.08.2021 um 22:53 schrieb Christophe JAILLET <christophe.jaillet@wanadoo.fr>:
>
>
> Le 30/08/2021 à 13:53, Eric Covener a écrit :
>> On Mon, Aug 30, 2021 at 7:36 AM stefan@eissing.org <stefan@eissing.org> wrote:
>>> In what state is our release handling? Given someone holding my hand, could I do it? Or is it better to look someone over the shoulder while he does it?
>> If there is an over-the-shoulder session I would like to tag along. I
>> am flexible on time of day but I am GMT+4 (EDT). I can host on webex.
>> Otherwise if you just want to struggle through it I can tag along but
>> I have no experience.
>
> I can give another try with my limited experience.
>
> I definitively would like to add a --dry-run option for all scripts so that they can be run for learning purpose without the fear of un-expected impact on svn.
>
> Existing scripts are not that easy to read at first, but are understanbdable and following http://httpd.apache.org/dev/release.html#how-to-do-a-release helps a lot. The scripts should also be tweaked because of the latest changes in several places (at least web site update (now on github) and CVE announcement (if any) now that part of the process is handled elsewhere).
>
> The CVE announcement should be much easier, now that we have a "Send these Emails" on cveprocess.a.o. This should simplify part of the process where we were preparing some scripts to send the announcement emails.
>
> I've been lacking time for httpd since many weeks, but I should be able to RM next week if needed.

I would like to look over your shoulder/help where I can. Maybe Eric can make a WebEx for us - that would make following along much easier, I guess.

Looking at the description link (thanks) I see that there are still a lot of "manual" things involved. And a "--dry-run" is definitely a thing we want. Will have a look at those scripts in the next days, to see what I can add here.

- Stefan
>
> CJ
>
>> Also: Anyone who has a showstopper to delay a release (even if not yet
>> proposed) please add it to 2.4.x STATUS so we can get things in order.
>>
Re: release? [ In reply to ]
On Mon, Aug 30, 2021 at 12:41 PM Yann Ylavic <ylavic.dev@gmail.com> wrote:
>
> On Mon, Aug 30, 2021 at 1:54 PM Eric Covener <covener@gmail.com> wrote:
> >
> > Also: Anyone who has a showstopper to delay a release (even if not yet
> > proposed) please add it to 2.4.x STATUS so we can get things in order.
>
> I think that BZ 65519 and 65521 are showstoppers, I'm waiting for
> feedbacks from the OP to commit to trunk and propose the backport, but
> if it lasts too long I'll do it anyway..

+1, that POLLHUP one was one I was thinking of.

Should we think about reverting the recent mod_unique_id changes? It
seems like that was noticed pretty quickly but I think the current
problem is still not well understood. Meanwhile the original problem
on the old codebase wasn't widely reported.
Re: release? [ In reply to ]
Le 31/08/2021 à 20:25, Eric Covener a écrit :
>
> Should we think about reverting the recent mod_unique_id changes? It
> seems like that was noticed pretty quickly but I think the current
> problem is still not well understood. Meanwhile the original problem
> on the old codebase wasn't widely reported.

+1

We can also easily narrow the time window where duplicate can be
generated by just reordering the previous code.

CJ
Re: release? [ In reply to ]
On 8/31/21 8:57 PM, Christophe JAILLET wrote:
>
> Le 31/08/2021 à 20:25, Eric Covener a écrit :
>>
>> Should we think about reverting the recent mod_unique_id changes?  It
>> seems like that was noticed pretty quickly but I think the current
>> problem is still not well understood. Meanwhile the original problem
>> on the old codebase wasn't widely reported.
>
> +1
>
> We can also easily narrow the time window where duplicate can be generated by just reordering the previous code.

Yes, looks like the old code base was "better". So let's do the improvement you mention and take some time for
reviewing the rewrite proposals that have been made on the Github PR.

Regards

Rüdiger
Re: release? [ In reply to ]
> On Aug 31, 2021, at 4:12 AM, Daniel Ruggeri <daniel@bitnebula.com> wrote:
>
>
> On 8/30/2021 3:53 PM, Christophe JAILLET wrote:
>>
>> Le 30/08/2021 à 13:53, Eric Covener a écrit :
>>> On Mon, Aug 30, 2021 at 7:36 AM stefan@eissing.org <mailto:stefan@eissing.org> <stefan@eissing.org> <mailto:stefan@eissing.org> wrote:
>>>> In what state is our release handling? Given someone holding my hand, could I do it? Or is it better to look someone over the shoulder while he does it?
>>> If there is an over-the-shoulder session I would like to tag along. I
>>> am flexible on time of day but I am GMT+4 (EDT). I can host on webex.
>>> Otherwise if you just want to struggle through it I can tag along but
>>> I have no experience.
>>
>> I can give another try with my limited experience.
>>
>> I definitively would like to add a --dry-run option for all scripts so that they can be run for learning purpose without the fear of un-expected impact on svn.
> FWIW, the announce.sh script which collates all the security "stuff" and sends the announce emails drops the user to a shell to inspect/examine what WILL happen before actually doing anything. Any non-zero return code of that shell will abort the process. I used the heck out of that several times :-)
>
>
>
>>
>> Existing scripts are not that easy to read at first, but are understanbdable and followinghttp://httpd.apache.org/dev/release.html#how-to-do-a-release <http://httpd.apache.org/dev/release.html#how-to-do-a-release> helps a lot. The scripts should also be tweaked because of the latest changes in several places (at least web site update (now on github) and CVE announcement (if any) now that part of the process is handled elsewhere).
>>
>
> +1
>
> To my knowledge, the publishing of the site and overhaul of the new CVE process are the things requiring updates.
>

The JSON files for the release’s CVEs should be committed here: https://github.com/apache/httpd-site/tree/main/content/security/json <https://github.com/apache/httpd-site/tree/main/content/security/json> : https://gitbox.apache.org/repos/asf?p=httpd-site.git;a=tree;f=content/security/json;hb=HEAD <https://gitbox.apache.org/repos/asf?p=httpd-site.git;a=tree;f=content/security/json;hb=HEAD>


> --
> Daniel Ruggeri
>> The CVE announcement should be much easier, now that we have a "Send these Emails" on cveprocess.a.o. This should simplify part of the process where we were preparing some scripts to send the announcement emails.
>>
>> I've been lacking time for httpd since many weeks, but I should be able to RM next week if needed.
>>
>> CJ
>>
>>> Also: Anyone who has a showstopper to delay a release (even if not yet
>>> proposed) please add it to 2.4.x STATUS so we can get things in order.
>>>
Re: release? [ In reply to ]
On 9/2/21 3:06 PM, Eric Covener wrote:
> Since you are going through this I wanted to mention:
>
> I think the public doc we have should mention everything that's done
> during ther release, even the security stuff that is somewhat private.
> The ASF-wide security policy is already public
> (https://www.apache.org/security/committers.html) and this is just the
> mechanics of it for us.
>
> Anyone object? This way we have one linear place to point to.

+1 Looks sensible. The details of an actual security issue should not be public until we make it so, but the procedure we use can be.

Regards

Rüdiger
Re: release? [ In reply to ]
The v2 release scripts in ^/httpd/dev-tools do now work for me
to create the tarballs, checksums and signatures for a release
vote and push them to dist.apache.org.

The steps after a vote need some more work. I will do that in the
coming days. However, since we can do a vote now, this is not that
pressing.

The "announce.sh" part should stay usable as it is. I have no plans
to update that one, since I have 0 experience what this really does
and where any problems/room for improvements are.

Cheers,
Stefan


> Am 02.09.2021 um 16:53 schrieb Ruediger Pluem <rpluem@apache.org>:
>
>
>
> On 9/2/21 3:06 PM, Eric Covener wrote:
>> Since you are going through this I wanted to mention:
>>
>> I think the public doc we have should mention everything that's done
>> during ther release, even the security stuff that is somewhat private.
>> The ASF-wide security policy is already public
>> (https://www.apache.org/security/committers.html) and this is just the
>> mechanics of it for us.
>>
>> Anyone object? This way we have one linear place to point to.
>
> +1 Looks sensible. The details of an actual security issue should not be public until we make it so, but the procedure we use can be.
>
> Regards
>
> Rüdiger
>