Re: squid-3 vs 2.6

Excellent email, thanks.

On 24 Jun 2006, at 10:34, Henrik Nordstrom wrote:

> To follow up on some discussion seen on IRC.
>
> featurewise it's relatively small stuff in 2.6 not in squid-3 yet.
> Some
> of the things in 2.6 is more polished than in Squid-3 however, but
> these
> differences should even out as Squid-3 QA progresses.

You say "relatively small" - but with the potential to cause lots of
instability. Do you agree that most of these missing features would
best be put in 3.1, after 3.0 has reached production stability?
Perhaps the smaller and less risky ones might be acceptable into
3.0... but we must be very careful.

>
> Missing features:
>
> - collapsed forwarding
>
> - WCCPv2
>
> - TPROXY
>
> - Connection pinning for relaying of Microsoft Integrated Auth.
>
> - ETag
>
> - Follow X-Forwarded-For
>
> - anything else?
>
> Polishing:
>
> - Parts of the SSL cleanup. Main requirements being the pending bits
> in the comm code, or refactoring solving this I/O operation
> independence
> differently.
>
> - Reasonable read defer management.
>
> - COSS ng (or whatever to call what Adrian is doing to COSS).
> Some of
> this actually fits better in Squid-3 with it's re-factored I/O
> framework.
>
> - >2GB objects
>
> - HTCP updates
>
> - Many small bugfixes here and there in the new features common to
> both trees.
>
> - probably a bit more

Let's make sure all of these are in Bugzilla against 3.0, so we've
got them quantified and in the public domain.

>
>
>
>
> What happened to Squid-3 was that there was a release plan which was
> nice and cool about a quick translation to C++ but feature wise
> identical to 2.5. Then re-factoring was done a bit too far bringing a
> slew of stability issues combined with a lot of new features added
> (the
> two goes hand in hand, and was unavoidable at the time) resulting in a
> considerably higher divergence from Squid-2 than planned, and around
> this Robert (the main architect of the Squid-3 rewrite) got another
> job
> requiring a change in priorities on his part. As a result for a long
> time we had a Squid-3 tree which was in the mid of very many
> changes all
> over the place, and the architect behind these changes buzy
> elsewhere..
> Also, some stuff was let into the tree a bit premature like the quite
> far going Range processing changes. With this situation there was not
> much choice but to continue developing in Squid-2 and forward porting
> the results to Squid-3 with the hope that the results will be
> useful the
> day Squid-3 shapes up..
>
>
> I have a feeling we now finally have the tree Squid-3 in a quite
> consistent state, but a lot of bug fixing naturally remains. Most
> of the
> Squid-2 bugs remaining in "port to Squid-3" status should however be
> taken mostly as hints there may be problems in these areas of Squid-3.
> In reality many of these likely doesn't exists in Squid-3, either from
> being fixed independently or re-factoring where the failing code has
> been rewritten eliminating the problem that way.. The majority of the
> expected Squid-3 bugs is likely unique to Squid-3, and not Squid-2
> patches not yet forward ported..
>
> To survive the main focus for Squid-3 MUST be to get the tree stable.
> Until we reach that point the community will continue to diverge as
> most
> customers still demands production ready deployment.
>
> I don't see it as a big problem if there is some features in Squid-2.6
> which maybe will not be seen in Squid-3.0, that's why there is a
> Squid-3.1 release. The Squid-3 tree already have sufficient amount of
> new unique features to draw attention. Customers who are in need of
> any
> such 2.6 only feature will have the choice of running 2.6 and missing
> the new features only available in Squid-3, or make sure the feature
> they need is forward ported proper closing the gap from 2.6 to 3.
>
>
> The 2.6 release is actually about focusing the community again. It's
> better to have two focused releases, than the past situation of nearly
> every installation (including binary vendor distributions) unique with
> different combinations of patches applied to the feature-wise ancient
> 2.5 release. Myself have been running something which maybe resembles
> 70% of 2.6, and it's hard to find any larger installation running a
> stock 2.5 release. This has been very evident on the squid-users
> discussions in the last years which increasingly has been about
> applying
> different feature patches to 2.5, which is not a good sign for the
> health of the project.

Thanks - good to know the history. I repeat what I said before about
having this kind of stuff on the website: we need an up to date News
section + homepage coverage. Otherwise only about 6 people in the
entire world know about it. What we're missing is an easy way to
update the main web content, otherwise it won't get done... Can we
port the entire website to the new Wiki?

>
>
> Regards
> Henrik

Squid-2.6 has filled a gap and bought us some time - customers have
extra features in a stable stock build. The next - and pressing -
priority for the community must surely be "Obsoleting Squid 2" before
that time runs out.

Would everyone on this list support the following:

1. No more 2.x development - new features must be against 3.x
2. Release 3.0.STABLE as quickly as possible (stability is priority,
still may lack features from 2.6)
3. Release 3.1 soon after that (feature complete, 2.6 is obsoleted)

I feel that if we don't put 2.x development finally to rest, 3.x will
never be allowed to overtake it, which is in nobody's interest. The
dilution of effort is also pretty shameful.

And I second the assessment that 3.0 is quite stable now. We should
unite behind it!

Cheers
Doug
Received on Fri Jun 23 2006 - 17:57:58 MDT