Re: Future squid development

Andres Kroonmaa wrote:

> What is reasonably stable? how many "crashes per million" requests? ;)
> For me reasonably stable is usable on a production box, because this
> the only place I'm using Squid.

Then you should maintain your own version, and once you have found one
that is stable only accept what you absolutely need in this.

> HEAD can be and is reasonably stable since branching from STABLE tree
> up until first DEVEL branch is merged into HEAD. Since that point
> claim "reasonably stable" isn't warranted until tested in numerous
> production environments. And as noone really uses HEAD in production,
> this stability claim is left unwarranted until next major release.
> I personally don't believe that HEAD can be made reasonably stable.
> Reasonably stable and creatively progressing development tend to be
> mutually exclusive. ;)

Not when done separately, which is the whole point here. Creative
programming are only allowed in HEAD when proven to work reasonably
well.

Having new feature developments based on the latest STABLE will be a
quite big burden when there is time to merge this with other
developments, and quite often there are dependencies between two
developments, making this even harder.

What you propose works well if the change is a isolated feature that
a) No other developments depends on
b) Does not depend on any other developments

But still, if you want it to be based on the latest STABLE release until
we are close to the next STABLE version then there will be a major work
in merging these together.

> In two words, I propose branching from HEAD a parallel tree to STABLE,
> that gets same bugfixes that STABLE receives, but also receives some
> of new features that HEAD receives, but not all, only those that do
> not need extensive stability-proof record. That way, this FEATURE tree
> stays based on latest STABLE, includes some new features committed to
> HEAD, and shouldn't become a headache to merge with HEAD - its based
> on HEAD, only a subset of it. Does that make sense?

You cannot base something on a subset of another branch, only the other
way around: a subset can be the base for the larger work.

> What this gives to people, is a branch that is untouched by DEVEL
> branch merges, yet includes small changes to STABLE that people find
> useful. And it allows to keep STABLE totally untouched by new feaures.

Sure. Then find someone (you?) who accepts taking the role of
maintaining what goes into this branch and when.

> The only assumption is that HEAD accepts patches against STABLE or
> this new FEAT tree. Is this possible?

Yes, sometimes, but not for very long. Quite soon there will be changes
in HEAD which makes it incompatible with FEAT/STABLE, making it a major
burden to apply the patches to all trees.

What might be manageable is if someone takes the role of maintaining
this FEAT release and backport changes from HEAD.

> Well, I personally don't believe there is such thing as always-stable
> Beta software. It is imho unrealistic to restrict major changes to
> only those that has production quality - this slows down development
> dramatically, causes some branches never finish. Eventually this means
> that HEAD is not usable on production boxes, meaning that is will not
> be used on production caches, and this leaves several useful new
> features from being used and tested by endusers.

Delaying inclusion until found stable is actually a good way to make
sure things gets finished.

Allowing unfinished changes into HEAD has a great risk in that it is
mostly the person(s) who made the change in the first place who
understands what needs to get done to finish the work, and it is not
much likelier they will finish it after inclusion.

/Henrik
Received on Wed Oct 04 2000 - 13:23:56 MDT