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
