Re: 2.4.35 in Sept?

[Jim Jagielski <ji...@jaguNET.com>]

If there is still interest, there are a handful of useful backports in STATUS that could use review, testing and voting :-)

> On Aug 29, 2018, at 10:10 AM, Jim Jagielski <ji...@jaguNET.com> wrote:
> 
> Looking to maybe do an interim release in Sept...
> 
> Comments? Feedback?

Re: 2.4.35 in Sept?

[Jim Jagielski <ji...@jaguNET.com>]

> On Sep 12, 2018, at 4:14 PM, William A Rowe Jr <wr...@rowe-clan.net> wrote:
> 
> On Tue, Sep 11, 2018 at 8:01 AM Jim Jagielski <jim@jagunet.com <ma...@jagunet.com>> wrote:
> If there is still interest, there are a handful of useful backports in STATUS that could use review, testing and voting :-)
> 
> Unless the goal is to replace one set of regressions with a new set 
> of regressions, it's past due to tag 2.4.35 before "useful" returns as 
> the de facto criteria again on 2.4.x.
> 

Certainly that is up to the RM and the people reviewing, testing and voting on the backports...

Re: 2.4.35 in Sept?

[Daniel Ruggeri <dr...@primary.net>]

Hi, Bill;
    I would be game for tagging and rolling 2.4.35 and 2.4.36 shortly 
after. I can volunteer to do both... in fact, with the scripts in place 
(but needing some minor cleanup, I think), I'm generally willing to T&R 
on-demand barring personal things that would keep me from doing so.

-- 
Daniel Ruggeri

On 2018-09-13 14:24, William A Rowe Jr wrote:
> I'm unaware of anything blocking a tag today, if someone wants to
> proceed. What is gained by waiting a few days to slip in another
> rushed patch to break yet another release? 
> 
> I see nothing in STATUS necessary to fix 2.4 regressions, but many
> proposed behavioral changes which suggest the likelyhood of new
> regressions. 
> 
> A minimal 2.4.35, and an optimistic 2.4.36 enhancement release within
> weeks of one another serves all interests, a stable 2.4 and early
> adoption 2.4. Users can back down to 2.4. 35 instead of way back to
> 2.4.29 or earlier, in the event of new issues in such a 2.4.36 release
> which includes TLS 1.3 support. 
> 
> On Thu, Sep 13, 2018, 14:09 Gregg Smith <gl...@gknw.net> wrote:
> 
>> On 9/12/2018 1:47 PM, Jim Jagielski wrote:
>>> 
>>> What improvements do you have to suggest to improve upon this? Do
>> you recommend a longer vote time? Do you recommend beta and/or
>> release-candidates? Do you recommend that the 1st born of all voters
>> be held in a camp until the release has "proven" itself to be up to
>> your satisfaction ensuring that said voters have "skin in the game"?
>>> 
>> IMO a couple extra days wouldn't hurt unless its fixing a 0day.

Re: 2.4.35 in Sept?

[William A Rowe Jr <wr...@rowe-clan.net>]

I'm unaware of anything blocking a tag today, if someone wants to proceed.
What is gained by waiting a few days to slip in another rushed patch to
break yet another release?

I see nothing in STATUS necessary to fix 2.4 regressions, but many proposed
behavioral changes which suggest the likelyhood of new regressions.

A minimal 2.4.35, and an optimistic 2.4.36 enhancement release within weeks
of one another serves all interests, a stable 2.4 and early adoption 2.4.
Users can back down to 2.4. 35 instead of way back to 2.4.29 or earlier, in
the event of new issues in such a 2.4.36 release which includes TLS 1.3
support.



On Thu, Sep 13, 2018, 14:09 Gregg Smith <gl...@gknw.net> wrote:

> On 9/12/2018 1:47 PM, Jim Jagielski wrote:
> >
> > What improvements do you have to suggest to improve upon this? Do you
> recommend a longer vote time? Do you recommend beta and/or
> release-candidates? Do you recommend that the 1st born of all voters be
> held in a camp until the release has "proven" itself to be up to your
> satisfaction ensuring that said voters have "skin in the game"?
> >
> IMO a couple extra days wouldn't hurt unless its fixing a 0day.
>

Re: 2.4.35 in Sept?

[Gregg Smith <gl...@gknw.net>]

On 9/12/2018 1:47 PM, Jim Jagielski wrote:
> 
> What improvements do you have to suggest to improve upon this? Do you recommend a longer vote time? Do you recommend beta and/or release-candidates? Do you recommend that the 1st born of all voters be held in a camp until the release has "proven" itself to be up to your satisfaction ensuring that said voters have "skin in the game"?
> 
IMO a couple extra days wouldn't hurt unless its fixing a 0day.

Re: Does httpd work with buildbot or considering buildbot

[Michael <ai...@felt.demon.nl>]

On 17/09/2018 13:15, Michal Karm wrote:
> Ad "Mustard after the meal", exactly what has been troubling me, so I stitched
> together this little Jenkins thing :-)
>
> Cheers
> K
>
> Michal Karm Babacek

Looks like I will have some work to do - in the coming days/weeks.

Re: Does httpd work with buildbot or considering buildbot

[Michal Karm <mi...@gmail.com>]

On 09/17/2018 01:01 PM, Michael wrote:
> On 12/09/2018 22:47, Jim Jagielski wrote:
>> The idea is that people actually take the time to download the tarballs, build a version of httpd for their use and then perform testing on said version such that they can vote on whether to release it or not. That testing entails such activities as running it through our test framework, putting it in a dev/prod environment to see how it works, etc... That is a schema that we have had for... let me see... years and decades.
> Curious. Does httpd work with buildbots as a way to test things. afaik
> it works without git repositories - although most seem to. If yes, I
> would be willing to dedicate some processing cycles from my server -
> assuming I can get it working.
>
> As far as downloading tarballs, etc. - done that in the past (although i
> am not a registered voter), but generally my 'results' are what the
> dutch call "Mustard after the meal" aka "too late to have any utility".
>
> In short, if yes, or when it moves towards yes - willing to helpout.
>
> Michael
>
>

For a one specific build flavour: MSVC + CMake on 64bit WIndows, I maintain
these, they poll Git daily:

2.4.x  https://ci.modcluster.io/view/Windows/job/httpd-windows/
trunk https://ci.modcluster.io/view/Windows/job/httpd-trunk-windows/
(arbitrary GitHub account is needed to see the Jenkins)

There is a trivial smoke test that loads all modules and tries HTTP and HTTPS.
The job does not execute the httpd test suite -- it's on my spare time roadmap
though...

Build script:
https://github.com/modcluster/ci.modcluster.io/blob/master/windows/httpd/build.bat

Ad "Mustard after the meal", exactly what has been troubling me, so I stitched
together this little Jenkins thing :-)

Cheers
K

Michal Karm Babacek

-- 
Sent from my Hosaka Ono-Sendai Cyberspace 7

Does httpd work with buildbot or considering buildbot (was: Re: 2.4.35 in Sept?)

[Michael <ai...@felt.demon.nl>]

On 12/09/2018 22:47, Jim Jagielski wrote:
> The idea is that people actually take the time to download the tarballs, build a version of httpd for their use and then perform testing on said version such that they can vote on whether to release it or not. That testing entails such activities as running it through our test framework, putting it in a dev/prod environment to see how it works, etc... That is a schema that we have had for... let me see... years and decades.

Curious. Does httpd work with buildbots as a way to test things. afaik
it works without git repositories - although most seem to. If yes, I
would be willing to dedicate some processing cycles from my server -
assuming I can get it working.

As far as downloading tarballs, etc. - done that in the past (although i
am not a registered voter), but generally my 'results' are what the
dutch call "Mustard after the meal" aka "too late to have any utility".

In short, if yes, or when it moves towards yes - willing to helpout.

Michael

Re: 2.4.35 in Sept?

[Jim Jagielski <ji...@jaguNET.com>]

> On Sep 12, 2018, at 4:14 PM, William A Rowe Jr <wr...@rowe-clan.net> wrote:
> 
> Since we still have no schema to solve the project maintenance side of
> shipping source code

Sorry, but we have this thing called creating test tarballs and calling for a vote. I am sure you remember that.

The idea is that people actually take the time to download the tarballs, build a version of httpd for their use and then perform testing on said version such that they can vote on whether to release it or not. That testing entails such activities as running it through our test framework, putting it in a dev/prod environment to see how it works, etc... That is a schema that we have had for... let me see... years and decades.

What improvements do you have to suggest to improve upon this? Do you recommend a longer vote time? Do you recommend beta and/or release-candidates? Do you recommend that the 1st born of all voters be held in a camp until the release has "proven" itself to be up to your satisfaction ensuring that said voters have "skin in the game"?

It is better to light a single candle than to curse the darkness.

Re: 2.4.35 in Sept?

[William A Rowe Jr <wr...@rowe-clan.net>]

On Tue, Sep 11, 2018 at 8:01 AM Jim Jagielski <ji...@jagunet.com> wrote:

> If there is still interest, there are a handful of useful backports in
> STATUS that could use review, testing and voting :-)
>

Unless the goal is to replace one set of regressions with a new set
of regressions, it's past due to tag 2.4.35 before "useful" returns as
the de facto criteria again on 2.4.x.

Because the TLS 1.3 patchset is significantly bigger, I'd appreciate
an httpd release prior to merging that effort. So we have 2.4.35 entirely
usable, and soon thereafter, 2.4.36 with TLS 1.3, and whatever "useful"
additions people want to pile on (as observed of the 2.4/trunk diff).

Since we still have no schema to solve the project maintenance side of
shipping source code, getting 2.4.35 with principally regression-fixes out
the door before new regressions are added seems wise. I'm happy to
offer to RM this coming Monday if nobody beats me to it, if we believe
all of the known regressions have been closed.

Is anyone aware of any lingering regression fixes to apply for 2.4.35
in the immediate-term?

September for 2.4.36 w/TLS 1.3 still seems plausible. If we really want
to prove up that patch set, 2.5.1-alpha sooner rather than later might
make good sense, and would likely attract more attention than a typical
alpha owing to draft TLS 1.3 support alone.