httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Graham Leggett <minf...@sharp.fm>
Subject Re: [proposed] 2.4 Maintenance SIG
Date Tue, 03 Jan 2017 14:46:17 GMT
On 03 Jan 2017, at 4:07 PM, William A Rowe Jr <wrowe@rowe-clan.net> 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.
> 
> Is there a very large architecture change planned by anybody?
> 
> In my experience, things that felt initially like big changes have actually turned out
to be rather modest changes that are still possible to backport to v2.4 without an issue.
For this reason I haven’t seen a reason to push very hard for v2.6, never mind v3.0.
> 
> I do, the very specific problem is that trunk/, and therefore all more-than-modest (or
just neglected) contributions are now four years stale and abandoned.
> 
> A certain way to push off contributors is to ignore their patch submissions. The second
method is to commit them to a dead fork.

I’m not following this logic.

The rules are patches are committed to trunk first, and therefore trunk is never dead by definition.
People either backport the change to v2.4, or they wait for 2.6. The backport to v2.4 happens
immediately, waiting for v2.6 either means “I’m happy to wait for v2.6” or it means
“I’m not happy to wait, so let’s release v2.6”.

This is how it has always been, and I see no problem with this pattern.

> 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.

We would obviously never do this, at to do so would treat our contributors with contempt.

> Beyond this, see the recent appeal for major.minor breaking change wish list on trunk/STATUS,
that is a different thread for you to chime in on.
> 
> Back to topic, who is interested in a stable release chain, since 2.4.x has not been
that?

I still don’t understand the problem you’re trying to solve, v2.4.x has certainly been
a very effective stable release chain. Or more accurately, I do not see any problem that cannot
be solved by our current process, which is a choice between the following:

- backport the stuff to v2.4; otherwise
- release v2.6 and continue.

Regards,
Graham
—


Mime
View raw message