httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Paul Querna <c...@force-elite.com>
Subject Thoughts on Future Versions/Backporting
Date Fri, 19 Aug 2005 14:58:13 GMT

Let me prefix this with, I don't want to start another CTR vs RTC war.

I do agree that CTR does add a major overhead to backporting Items to
the 'stable' branch.

I wish to avoid this overhead in the STATUS file.

I think part of our problem is that we backport too much.  We currently
backport security fixes, small bug fixes, big bug fixes, and even
complete subsystem rewrites.

I believe that a more scalable design, is that "we" should try to only
backport small items.  This has several major effects, like making it
easier to vote on items in the STATUS file, since it is generally easier
to understand a single two line bug fix, rather than an entire rewrite
of a module.

This also means that most "new features" would wait for the "next
stable" version to be released.  If the "next stable" isn't a 3 year
cycle like 2.0->2.2, I believe this could be acceptable.

I believe that we should have more stable branches, more often.  I
believe that we should try to only backport bugfixes and security issues
to these branches, and attempt to avoid adding many new features.

I don't want to force the hand of any other committer, or group of
committers.  If others want to vote and backport every new feature from
the development branch, they are welcome to it.

If people like the idea of only doing small backports, perhaps we can
add such wording to the versioning document.

At a personal level, I intend to only help backport small items, and I
will help with creating stable branches more often, to get all our new
features out to users.

-Paul


Mime
View raw message