Re: Future squid development

Andres Kroonmaa wrote:

> you mean, including unfinished total rewrite also, for eg?

Well, not until there is a consensus on that the rewrite is a good
thing, and in a reasonably useable shape.

> So, until HEAD-based new Stable is released, HEAD is pretty much
> unstable and unusable, right?
> Make it clear, how stable is it compared to 2.3Stable4?

Well, personnally I don't think we actually have had any stable 2.X
releases yet, but that is another discussion.

My goal HEAD should stay reasonably stable, but will quite likely be
somewhat less stable than the latest STABLE branch. HEAD is not bleeding
edge developments.

> ie, currently 2.4devel? or is it 2.3stable-latest?

Currently it is 2.4.DEVEL, but soon 2.4 will branch off from HEAD.

> Whats been frustating me abit is that it is quite hard to find out
> what is what. What the HEAD is based on, how stable it is, etc. If
> I understand it right, then HEAD is currently 2.4, alpha, and noone
> even really knows how stable it is on production box, because noone
> really uses it.

2.4 is in somewhat a moment 22 condition right now yes. It is at the end
of it's development cycle, but very few dare to test it out which gives
quite little feedback on how (un)stable it actually is.

> Usually, when people feel that it is time to make a new stable
> release, then spike of activity starts during which some good
> coders take a very close look at the code and bring it up to
> stable. Then its released and during some few months several new
> releases are made with often critical fixes.

2.4 has been there several times already, but then time goes and new
things comes in...

> This is very discouraging to use HEAD as your development platform.
> I have to date sticked with latest Stable and hacked on it. At least
> I have a solid ground and blame myself first when I screw it.

I don't think this has actually been much of a problem for the
development projects based on HEAD.

> And I have a good reference point, snapshots or devel-HEAD are moving
> targets. If you are not too much CVS-guy, then it isn't attractive.

Well, you do not need to care about much of the CVS magics. This has
been taken care of by semi-automatic scripts already.

> hmm. isnt these daily snapshots just bugfixes to stable? ie. latest
> current snapshot is early 2.3Stable5 ? And btw, why daily, why not
> "only if changed"?

Sure, you can probably change the script not to make a snapshot if there
hasn't been any changes.

The snapshots of the STABLE branch(es) is STABLE+bugfixes.

The snapshots of the HEAD branch is new features and bug fixes.

> And do you mean that Cygwin and NTLM branches would appear here after
> merging?

Whatever new features gets merged into HEAD appears in HEAD, but not in
STABLE until a new version STABLE branch is made from HEAD..

> What I'm aiming at is that new HEAD should be branched from latest
> STABLE immediately after first STABLE release, next release ver
> (DEVEL) be based on that HEAD, and all branches based on that HEAD.
> All critical changes should be hacked on DEVEL and left out of HEAD.

Yes? This was exacly what I began my letter (except that the branching
is reversed). All development are performed on branches, and not until
the change is found reasonably stable will it get merged into HEAD.

> When a new feature (branch) is reaching stable state, it is
> committed to HEAD (and thus automatically to DEVEL).
> When DEVEL reaches milestone of releasing new Stable, then all
> features of HEAD are reevaluated, cleaned up, integrated with
> changes in DEVEL, and new STABLE released. After that old HEAD is
> retired and no new updates to it.

Ok. Sligthly different then, and I think this is pretty much overkill,
and will quite likely slow down things even more.

To keep things moving I think the evaluation process needs to be
incremental to keep the HEAD revision reasonably clean at all times, not
only when a new STABLE branch is about to start.

> Old STABLE continues to have updates by bugfixes for some time.

Granted.

> New HEAD is spawned from new STABLE immediately and new circle begins.

Technically it is the other way around, but the effect is the same I
think.

> If this is currently the case, then I only wish to see more clear
> description of that on the web.

It is mostly this case for the projects which are not working directly
IN HEAD.

> For me, to date 2.3.STABLE-hno has been closest to what I want, ie.
> latest Stable + more). What I'd like to see is that there is 2.3HEAD4,

2.3.STABLE-hno is purely bugfixes that in my opinion should have gone in
into 2.3.STABLE long time back. I won't go into the reasons to why this
hasn't happened here.

> If latest Stable-HEAD isn't stable, people could revert back to
> previous or STABLE, or take that HEAD and get it fixed.

The STABLE branches should be STABLE. No point in arguing about that.

> well, maybe my naming isn't correct, I don't know. Maybe multiple
> HEADs don't even make sense from CVS perspective. Maybe we should
> call it STABLE+NEWFEARURES (eg. 2.3STABLE4-NF, or smth)

2.3.STABLE-hno is not this.

2.2.STABLE-hno was like the above due to various reasons, and nothing
stops anyone from making such a branch again.

CVS works with a version tree. HEAD is the trunk of the tree, with
branches taking off from it.

What we have on squid.sourceforge is tools to

a) Have a branch track the HEAD so it always starts from the top of the
tree

b) and tools to make branches from these branches to allow straight
dependencies between developments, where development B depends on the
changes in A which is not yet mature enought to get merged into HEAD.

c) "Tools" to merge a branch into HEAD

d) It is also possible (but discouraged) to make super-branches that
attaches to two or more of these branches and track changes in both (and
indirectly HEAD via the other branches).

So in this cenario you can view the version tree as one main trunk with
the STABLE releaes (2.1, 2.2, 2.3, 2.4, ...) branching off from it. At
the top there is a ring of various development branches, and at the tip
of some development branches there might be further branches with
depending developments.

Then at times you can see that development branches gets consumed by the
trunk and the trunk grows upwards by displacing the development branch
to becoming the new top of the trunk.

On trunk there can also be seen a few abandoned development branches,
branching off from the trunk at the time they was abandoned.

> My point was that there are different kinds of new features, radical
> and not so radical. For eg, modio cannot be merged with latest stable,
> as it needs some redesign in squid, but commloops could be.

Sure.

> Yet I cannot really participate in commloops easily because its
> based on something I understand is unstable. I have no time nor
> resources to test it on separate box. But if I knew its based on
> stable release, I'd run it on my production boxes and would iron
> out any bugs I discover. Adrian is also in some trouble developing
> it, because he has very little feedback, and it won't appear before
> next release(2.4) is out. This also doesn't encourage to wrap it
> up yet, isn't it?

There is also a flipside of the coin. Doing such developments based on
STABLE quite quicly makes it a major headache to later merge it with the
other developments. Merging is quite easy when done incremental, but
merging a major change from a 2.3 tree to a 2.4 tree is not. In fact
sometimes it might be close to impossible and basically has to be redone
from scratch (this happened with several of my Squid-2.2 changes).

So my opinion is that it is better to simply try to have HEAD reasonably
stable at all times.

I think it is quite reasonable to request from you and other users that
if you want to test a new feature, then you will also get the other new
features which has been classified as reasonably stable by the
developers.

> Of course, I'm not insisting on anything, I just feel that some
> features should be added to public for use before next major release
> and after feature-freeze, besides to stable tree.

Partly agreed, and I think you will see that the proposed approach
actually gives this by restricting HEAD to only have changes which has
passed a review and found reasonably stable.

modio is one such change. It has passed a quite extensive review, and
most stability problems in modio is also shared with the latest STABLE.
Sure there has been a few modio specific bugs found and perhaps a few is
still there, but the majority of the bugs was killed before it went into
HEAD.

What was lacking at that time was a good test environment to evaluate
the stability and performance effects of the change. However, this is
now in place as well thanks to a sponsor who has accepted to run these
tests.

Yes, there are some remaining open issues with modio, but those are
mainly in design and performance, not stability.

/Henrik
Received on Wed Oct 04 2000 - 01:35:13 MDT