Re: Future squid development

On 2 Oct 2000, at 23:18, Henrik Nordstrom <hno@hem.passagen.se> wrote:

> There is a fair bit of development effors waiting to get into Squid, and
> to ease the development during the next development cycle I'd like to
> propose the following:

 Would someone describe what "HEAD" exactly means? squid-2.4-devel?
 Does it mean development tree with potentially drastic changes, or is
 it stable + new (relatively stable) features only?

> * All developments are done in separate branches until tested
> (preferably on squid.sourceforge.net, but a separate branch on
> squid-cache.org is OK if you don't agree with this). Only changes which
> have been tested by at least two developers gets committed to HEAD, and
> only after first being presented in both reasoning and patch format on
> squid-dev.

 I would like to see that new features are developing in hand with stable,
 to encourage people who need the features to use them asap. Often people
 need more than 1 feature, so use of single branch is not what they want.
 In this sense it seems good to consider "HEAD" to be a place where all
 new features are integrated. Unfortunately it seems that current HEAD
 is based on devel that is far from stable. I think we would like HEAD
 to be (semi)stable releases. This means that drastic changes like large
 rewrites that may make release unstable should be made to next devel
 tree. Therefore I think it would be nice if we make difference between
 versions of "HEAD" - one that is based on stable should be expected to
 be stable, and the one that is based on next version is expected to be
 beta/devel grade. Whether a branch should be committed to stable-head or
 devel-head would be decided by developers.

 2.3stable-X (+bugfixes only)
  - branch1(untested)
  - branch2(tested.commit)
  - branch3(tested.commit)
  - branch4(new-untested)
 2.3head-X.y (2.3stable-X + bugfixes + branch2 + branch3 )
  - head-branch5-untested
 ...
   2.4devel (integrate 2.3head(committed) + large changes)
   ... (lots of bugfixes)

 2.4stable (2.4devel in decent debugged state, wrapped up)
  - branch1(tested.commit)
  - branch4(untested)
  - branch6(new-untested)
 2.4head (2.4stable + branch1 )
 ...
   2.5devel

 This imho should allow people who like to be on the very edge to use
 head version on their production caches, and help us find the bugs that
 got unnoticed by developers. This should help us speedup reaching stable
 status alot. People who don't want new features can stick with stable.
 Also, developers themselves may depend on head version, and as they need
 yet new feature for their own production caches, may decide to wait until
 features in head they need reaches stable status of next version, before
 they start looking at adding their own changes. I think this may slowdown
 and discourage development. Also, some patches that don't need their own
 branch, may be pushed to stable-head directly.

 In general, I think we should have a version that fits between Stable
 and Beta of next version, and be usable on production caches. Such
 version should be based strictly on currently stable version, and only
 differ from it by new committed features added to it.

 So, we should have 2 heads: Stable-head and Devel-head, I think.

> * New STABLE releases are automatically made 4 weeks after the last
> change, even if the change is quite small.

 I think release of new stable version should be indication to people
 that upgrading to it should increase stability or performance of squid.
 In this sense, it seems unreasonable to release new stable too soon if
 only cosmetic changes have been made (like changes to error pages for eg)?
 If operational changes have been made, then perhaps we should release
 sooner? 2weeks?

------------------------------------
 Andres Kroonmaa <andre@online.ee>
 Delfi Online
 Tel: 6501 731, Fax: 6501 708
 Pärnu mnt. 158, Tallinn,
 11317 Estonia
Received on Tue Oct 03 2000 - 04:14:02 MDT