Re: [proposed] 2.4 Maintenance SIG

On 03 Jan 2017, at 2:11 AM, William A Rowe Jr wrote: > So far, discussions are polarized on a single axis... > > East: Let's work on 3.0; whatever is going on in 2.4 won't distract me, I > won't spend time reviewing enhancements, because 3.0 is the goal. > > West: Let's

Re: svn commit: r1775789 - /httpd/httpd/branches/2.2.x/STATUS

I am not completely following how the branch or patch were assembled, but I am seeing a failure that is missing content from the initial trunk work (1426877) that was also in the initial 2.4.x backport (1772678). It is causing frequent crashes on EOF of a keepalive conn for me The missing bit

Re: [proposed] 2.4 Maintenance SIG

> On Jan 2, 2017, at 7:11 PM, William A Rowe Jr wrote: > > So far, discussions are polarized on a single axis... > > East: Let's work on 3.0; whatever is going on in 2.4 won't distract me, I > won't spend time reviewing enhancements, because 3.0 is the goal. > > West:

Re: [proposed] 2.4 Maintenance SIG

>Nobody built on Windows prior to the release so >we had a re-roll. Please contact me before a release, so I can test. Steffen AL --- Begin Message Group: gmane.comp.apache.devel MsgID:

Re: The Version Bump fallacy [Was Re: Post 2.4.25]

Back in the "old days" we used to provide complimentary builds for some OSs... I'm not saying we go back and do that necessarily, but maybe also providing easily consumable other formats when we do a release, as a "service" to the community might make a lot of sense.

Re: [proposed] 2.4 Maintenance SIG

On Mon, Jan 2, 2017 at 7:11 PM, William A Rowe Jr wrote: > So I'd like to know, in light of a perpetual chain of (often build and/or > run-time breaking regression) enhancements, if there is support for a > 2.4.24.x release chain during the 3.0 transition? And support for >

Re: [proposed] 2.4 Maintenance SIG

On Jan 3, 2017 02:19, "Graham Leggett" wrote: Can you clarify the problem you’re trying to solve? v3.0 and v2.6 are just numbers. For modest changes, we move to v2.6. For a very large architecture change (for example, the addition of filters in v1.x to v2.x), we move to 3.0.

Re: The Version Bump fallacy [Was Re: Post 2.4.25]

On Jan 3, 2017 07:11, "Jim Jagielski" wrote: Back in the "old days" we used to provide complimentary builds for some OSs... I'm not saying we go back and do that necessarily, but maybe also providing easily consumable other formats when we do a release, as a "service" to the

Re: [proposed] 2.4 Maintenance SIG

On 03 Jan 2017, at 4:07 PM, William A Rowe Jr wrote: > Can you clarify the problem you’re trying to solve? > > v3.0 and v2.6 are just numbers. For modest changes, we move to v2.6. For a > very large architecture change (for example, the addition of filters in v1.x > to

Re: svn commit: r1775789 - /httpd/httpd/branches/2.2.x/STATUS

On Tue, Jan 3, 2017 at 9:55 AM, Eric Covener wrote: > I am not completely following how the branch or patch were assembled, > but I am seeing a failure that is missing content from the initial > trunk work (1426877) > that was also in the initial 2.4.x backport (1772678). > >

Re: svn commit: r1775789 - /httpd/httpd/branches/2.2.x/STATUS

On Tue, Jan 3, 2017 at 11:04 AM, William A Rowe Jr wrote: > On Tue, Jan 3, 2017 at 9:55 AM, Eric Covener wrote: >> I am not completely following how the branch or patch were assembled, >> but I am seeing a failure that is missing content from the initial

Re: [proposed] 2.4 Maintenance SIG

Bill, your Email client is messed-up again, as related to how it handles copy/pasted text in replies. > On Jan 3, 2017, at 9:07 AM, William A Rowe Jr wrote: > > On Jan 3, 2017 02:19, "Graham Leggett" wrote: > > > Can you clarify the problem you’re trying

Re: A new release process?

On 12/29/2016 08:16 PM, David Zuelke wrote: The tl;dr of this approach is that - any x.y.z release only introduces bugfixes. These releases are done every four weeks, like clockwork. If a fix doesn't make the cut for a release, it'll end up in the next one; - x.y.0 releases, on the other hand,

Re: The Version Bump fallacy [Was Re: Post 2.4.25]

On 03/01/2017 23:11, Jim Jagielski wrote: > Back in the "old days" we used to provide complimentary builds > for some OSs... I'm not saying we go back and do that necessarily, > but maybe also providing easily consumable other formats when we > do a release, as a "service" to the community might

Re: The Version Bump fallacy [Was Re: Post 2.4.25]

On Tue, Jan 3, 2017 at 7:04 PM, Noel Butler wrote: > > On 03/01/2017 23:11, Jim Jagielski wrote: > > Back in the "old days" we used to provide complimentary builds > for some OSs... I'm not saying we go back and do that necessarily, > but maybe also providing easily

Re: [proposed] 2.4 Maintenance SIG

On 01/02/2017 04:11 PM, William A Rowe Jr wrote: So far, discussions are polarized on a single axis... East: Let's work on 3.0; whatever is going on in 2.4 won't distract me, I won't spend time reviewing enhancements, because 3.0 is the goal. West: Let's keep the energy going on 2.4

Re: [proposed] 2.4 Maintenance SIG

On 01/03/2017 06:07 AM, William A Rowe Jr wrote: If trunk/ is a dead fork, it may be time for httpd to admit this, trash it and re-fork trunk from 2.4.x branch. I don't feel that trunk is a dead branch, but I do think there is dead code in trunk. The CTR policy contributes to that, IMO, but

Re: Automated tests

On 12/30/2016 02:55 PM, Stefan Fritsch wrote: Yes, httpd lacks unit tests. One problem is that many APIs depend on very complex structs like request_rec, conn_rec, server_conf, etc. In order to write unit tests for such APIs, one would need to write quite a bit of infrastructure to set these