Re: Squid-3 release cycle

tis 2007-04-10 klockan 21:38 -0600 skrev Alex Rousskov:
> Squid 3.1 is whatever comes after a stable 3.0 release. Open to
> experimentation. Not currently branched (but could be if needed).

I think it might be wise to branch Squid-3.0 after PRE6, and that the
model currently used for Squid-2 is then applied to Squid-3 as well.

- HEAD always kept open for new reasonably stable stuff, allowing
development to progress natuarlly without having completed stuff
bitrotting in some seldom looked at development branch.
- If problems is seen in HEAD they get fixed, or the changes causing the
problems is thrown out back to their development branch until fixed.
- Stuff which seem to have settled gets merged to the stable branch by
the release manager (in person or delegated to patch owner whatever
suits the release manager).

This works very well at least as long as HEAD and the stable branch
hasn't diverged too much. And if they have diverged too much it's
probably time to plan a new stable version before long..

With the unordered development process we have it's very hard to build
firm plans on what features will be in a certain release before it's
there. It very much depends on what the active developers at the time is
working on.

What is important for the project survival is that HEAD is kept
reasonably stable and always suitable as development reference, and that
developments is merged incrementally when possible to catch problems
early without sacrificing the stability criteria too much.

> > Question then becomes, where is the existing list of agreed features
> > for 3.0-STABLE1 ??
>
> Whatever features have been committed already minus unstable optional
> features.
>
> This is just my understanding, of course. Not claiming to express the
> elusive consensus here...

Shared here. But I'd probably not minus the unstable optional features,
just not having then enabled by default and marked as experimental.

Squid-3.0 was originally supposed to match Squid-2.5 except being C++.
It's already far beyond that. Sadly over time Squid-2 and Squid-3 has
diverged a bit from each other and for the foreseeable future there will
be some features "missing" in Squid-3 only to be found in Squid-2. But
assuming Squid-3 gets stable it should quickly gain ground and the gap
from Squid-2 will shorten as people gets interested in what Squid-3 can
provide and there gets some motivation to get the important missing
things to Squid-3 as well. Some of the missing things probably isn't
very important, and can be left to rot in Squid-2 when focus gets moved
to Squid-3.

The probably biggest yell from users will be the lack of support for
passthru connection oriented authentication (NTLM/Negotiate/Kerberos),
aka connection pinning. The rest of the feature gaps is pretty minor I
think.

Internally the gaps is a bit bigger, especially at the comm layer where
the comm loops of Squid-2 is much lighter.. but both is definitely
hitting the wall when it comes to SSL and how to integrate it into the
comm loops in a sane manner and there is need for some serious thought
on how the comm layer should look like, which if done in Squid-3 will
most likely bring it far ahead of Squid-2 in that area.

Regards
Henrik