httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jacob Champion <champio...@gmail.com>
Subject Re: [proposed] 2.4 Maintenance SIG
Date Wed, 04 Jan 2017 16:55:09 GMT
On 01/04/2017 08:42 AM, William A Rowe Jr wrote:
> On Wed, Jan 4, 2017 at 9:47 AM, Graham Leggett <minfrin@sharp.fm> wrote:
>> That’s not dead code, that’s just the difference between v2.4 and trunk.
>
> So long as the project chooses not to release it, it sits in a repository DoA.

To a certain extent we'll have to do that, because breaking changes 
can't be backported, and we shouldn't put huge breaking changes on a 
short release cadence. I'm not counting unreleased breaking changes in 
my assertion of "dead code", and I certainly don't think all of the 
2.4->trunk diff is dead and useless.

(I'm currently working on reviewing the diff to answer Graham's 
question; it'll take a little while.)

> One of the interesting assertions is that C-T-R -> Trunk, R-T-C Trunk
> -> 2.4 is the correct and customary state of contributing to httpd.
>
> At one time this project operated in C-T-R -> Trunk -> Release mode.
> It would be productive to return to that model.

I'm not following this jump. If anything, I'm not a fan of CTR to begin 
with for a security-critical code base, *especially* if we're 
considering spinning a release candidate out of a branch that has 
unreviewed patches in it, but that's pulling the conversation in 
directions it doesn't need to go right now. I will bring that back up 
later, in a more appropriate thread.

> The goal of R-T-C on 2.4.x is simply to eliminate (unsuccessfully) ABI
> breakage and regressions between subversion releases.

The goal of RTC should be to *review* -- to ensure code quality, catch 
problems that aren't caught with tests (ABI, security, etc.), and so on. 
Catching regressions should be the goal of the test suite.

--Jacob

Mime
View raw message