On 03 Jan 2017, at 4:07 PM, William A Rowe Jr <wr...@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 —
smime.p7s
Description: S/MIME cryptographic signature
