Re: squid-3 vs 2.6

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Doug Dixon wrote:
> 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!

+1 for this plan.

Tres.
- --
===================================================================
Tres Seaver +1 202-558-7113 tseaver@palladion.com
Palladion Software "Excellence by Design" http://palladion.com
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2.2 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFEnKkn+gerLs4ltQ4RAlTpAKCIyeHxBXlqlp5pvIBPL3ReZuO7SACgunXG
agAKSJQhG2EXNUWQzMJUuQ8=
=AHBE
-----END PGP SIGNATURE-----
Received on Fri Jun 23 2006 - 22:05:04 MDT