Re: Future squid development

Andres Kroonmaa wrote:

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

HEAD is a CVS term for the HEAD revision which is the newest bleading
edge version.

Then from the HEAD version you have branches when a release stabilizes
and gets a live of it's own, such as the STABLE releases for Squid.

HEAD is always the current development version of the Squid which is
meant to be the next Squid version someday.

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

The trick is to do it without having a nightmare at the same time.

I already have a well tested and established framework for concurrent
development of new features with dependencies. However, if one want's to
combine two experimental features into a custom Squid release then there
often is more problem than it is worth, but it is defenitely doable as
long as the changes does not overlap (5 line margin, plus general design
of course).

For development the above is not a big problem as long as your
development depends on a limited amount of other changes which have not
yet matured.

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

Well, I think you are actually aming at the same goal here.

The goal is to allow expermental features to rapidly develop without
having a negative impact on the overall stability of the Squid release,
and to allow rapid inclusion of these into the distribution once tested
and proved useful.

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

Exacly. This is why experimental should not be done in HEAD. Only when
the change is reasonably tested and documented it will be allowed to
enter the HEAD version.

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

All active development versions inherit from HEAD. This is also the push
for people to complete their changes.

> Also, some patches that don't need their own branch, may be pushed
> to stable-head directly.

Pure bug-fix patches are allowed on HEAD without being developed in a
separate branch first.. (the working tree of the developer is sufficient
separation there).

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

This we already have in the nightly snapshots. The question is if we
should branch off a Squid release from HEAD prior to releasing the first
STABLE version, or if new features should be deferred while the next
release matures to STABLE.

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

HEAD is what will become the next Squid version.

Then for each Squid version there is also a current revision which is
the head of that branch.

> I think release of new stable version should be indication to
> people that upgrading to it should increase stability or
> performance of squid.

If you look in the patch history you will notice that patches for STABLE
are mostly bug fixes. The 4 week period is to guarantee that the patch
is stable before everyone jumps at it.

> 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)?

Then don't make such changes in STABLE and instead defer them to the
next version.

> If operational changes have been made, then perhaps we should release
> sooner? 2weeks?

Sometimes that can be warranted yes, but not very often. After all, the
idea is that critical bugs should have been discovered before the
version enters STABLE in the first place.

/Henrik
Received on Tue Oct 03 2000 - 14:16:31 MDT