httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From William A Rowe Jr <>
Subject Re: [proposed] 2.4 Maintenance SIG
Date Thu, 05 Jan 2017 21:43:20 GMT
On Thu, Jan 5, 2017 at 12:50 PM, Jacob Champion <> wrote:
> On 01/04/2017 11:55 AM, Graham Leggett wrote:
>> On 04 Jan 2017, at 8:37 PM, Jacob Champion <> wrote:
>>> So, there's 3k of the 20k. And remember, my point was that we can
>>> fix what I call "dead code" with good old fashioned legwork. I
>>> don't advocate trashing trunk, and I don't think having "dead code"
>>> is a disaster or a stain on anyone here. I just don't think it's
>>> appropriate to spin up an RC from trunk as-is.
>> Look for the discussion that occurred around November 2011 when v2.4
>> was released:
>>  We came to the same conclusion then.
> I started a longer reply to what you wrote earlier in the email, but I think
> I need to clear up any misunderstandings I have with this part first.
> From offlist discussions I've had with other committers (and Bill's recent
> reply to this thread), my understanding was that an alpha/beta branch would
> be forked from the current tip of trunk, followed by testing and additional
> feature work, until a .0 release is voted on.
> The conversation you linked to appears to modify that somewhat: we started
> tagging trunk directly with alpha/beta, and at some point decided to fork a
> 2.4.x from a mostly current trunk. It also adds the information that 2.4.x
> was still CTR, up to the .0 release. But in both cases, the statement "we
> plan to fork 2.6.x from a current-ish trunk commit" seems to hold up pretty
> well.
> Is that correct?

Following past practices, and a desire to reduce the amount of effort by
committers, I'd strongly object to a fork before 3.0 (or 2.6) is finalized.
It's a procedural-process sort of question, so it's a straightforward PMC
majority vote.

I'm also against forking at 3.0 or 2.6 until someone wants to introduce
an API breaking change, unless we solidify some new process for having
more predictable and frequent bug fix releases and split these from our
constant churn of feature changes. In that case, feature changes do map
well to trunk until there is a breaking ABI change, while we would need to
collect such bug fixes on a new branch.

View raw message