On 01/04/2017 08:42 AM, William A Rowe Jr wrote:
On Wed, Jan 4, 2017 at 9:47 AM, Graham Leggett <minf...@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
