-----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 [EMAIL PROTECTED] 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-----