Re: squid-3 vs 2.6
tis 2006-06-27 klockan 08:22 +0800 skrev Adrian Chadd: Which reminds me, I should really spend some time making sensible defaults when COSS is using AUFS - right now the aiops code doesn't create any threads because n_aufs_dirs (or whatever it is) is set to 0; one has to override it by the ./configure option (--with-aufs-threads=). That will get rid of at least one runtime problem (ie, no IO threads, so COSS doesn't do anything :) Been thinking many times about splitting the aiops threads per cache_dir, which besides solving the above problem also gives much better load calculation. Regards Henrik signature.asc Description: Detta är en digitalt signerad meddelandedel
Re: squid-3 vs 2.6
sön 2006-06-25 klockan 17:43 +1200 skrev Doug Dixon: - Parts of the SSL cleanup. Main requirements being the pending bits in the comm code, or refactoring solving this I/O operation independence differently. Bug #1633. - Reasonable read defer management. Bug #1634 - 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. This is already on Adrians schedule. Not sure there need to be a bugzilla entry.. - 2GB objects Bug #437. - HTCP updates Bug #1635. - Many small bugfixes here and there in the new features common to both trees. - probably a bit more We have to take these on a case by case basis as they are encountered in 3.0 I think. Regards Henrik signature.asc Description: Detta är en digitalt signerad meddelandedel
Re: squid-3 vs 2.6
On Tue, Jun 27, 2006, Henrik Nordstrom wrote: - 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. This is already on Adrians schedule. Not sure there need to be a bugzilla entry.. I'd love it if people would put their COSS-related crashes into Bugzilla. This probably won't happen until Squid-2.6 is -STABLE and people try out COSS. :/ Which reminds me, I should really spend some time making sensible defaults when COSS is using AUFS - right now the aiops code doesn't create any threads because n_aufs_dirs (or whatever it is) is set to 0; one has to override it by the ./configure option (--with-aufs-threads=). That will get rid of at least one runtime problem (ie, no IO threads, so COSS doesn't do anything :) Adrian
Re: squid-3 vs 2.6
Hi Henrik, At 23.28 24/06/2006, Henrik Nordstrom wrote: lör 2006-06-24 klockan 18:57 +0200 skrev Guido Serassio: Here I agree about the reasons, but I am doubtful about a 3.0 with not all the 2.6 features: It's a simple matter or project priorities. With no doubt the absolutely highest priority for Squid-3 must be get a stable release out as soon as possible. The more new features added the longer this will take. Sure, I agree about this. why someone will downgrade its proxy ? Why not? And if they don't want to they have the choice of making sure they don't need to. Why is Squid-3 completely outside it's original release plan, and still no-one knowing when it's reasonable to expect a stable release? You wrote The 2.6 release is actually about focusing the community again. This is happening because 2.6 include a lot of feature needed in real production environments, features already developed for 2.5 often with a customer sponsorship. But I'm not so sure that the current feature set of 3.0 could generate the same attention in the community: the general lack of sponsorship for the development of 3.0 features (with the exception of ESI and ICAP) is a worrying signal. Just for example: all my customers are waiting for connection pinning with open arms Then I am pretty sure at least one of them is willing to sponsor the development and bug fixing required to get that feature in squid-3, making it available as a patch to the Squid-3.0 release early on, and then merged into 3.1. Currently Italy is a worse market for Open Source Development: The majority of the company are too little to support any kind of sponsorship, while the whole national economy is still near to recession. Today in Europe only Greece if worse than Italy :-( Or if you prefer spending your time implementing the connection pinning for 3.0 instead of fixing bugs then you are very welcome to. When complete and tested in production it's a candidate for merging. If good it may make it into 3.0, else 3.1. This could be the only feasible way, but for me there is only a problem here: C++ .. :-( But this is OT to this thread ... I remember the proposal when 2.6 work was announced: 1) 3.0 initially mainly for high end reverse proxies (ICAP ESI) and 2.6 for forward proxies 2) 3.1 for both usage with all features. It seems to me a good compromise for a customer. I am not sure even 3.1 will be 100% feature complete. I don't think we as a team can bind to that promise as it's very dependent on what other tasks each of us take for the 3.1 release. The most important is that we make progress. If this means some features is deferred so be it. There is no sponsor behind this project who work on such generic scale as feature complete. Customers mostly pay for what they need, i.e. bug fixing of the issues they run into or features they need. This one of the reasons because I like to have a 3.0 release mainly focused on its new features related to reverse proxies, it will be the only way to justify a feature limited release to the community and to customers. I think that to ask to a customer a sponsorship for the forward port into 3.x of a feature already available in 2.6 is not a good product marketing Outside that we can not force anything on anyone else than yourself. * Any release plans depending on forcing something to get done is a risky one. * Open Source development works by interest, not force. * The single thing holding Squid-3 back is the fact that it's not stable. Until Squid-3 is stable it's very hard to shift development over there, and even harder to draw customer attention. Sure, it's not mandatory (and cannot be) to have a 3.1 release 100% feature complete, it could be a 3.x as well. But before of a feature complete stable 3.x release, we will have always a 2.x release needing to be maintained and eventually developed, with more wasting of our limited developing capability. We are in a very ugly stall situation. Regards Guido - Guido Serassio Acme Consulting S.r.l. - Microsoft Certified Partner Via Lucia Savarino, 1 10098 - Rivoli (TO) - ITALY Tel. : +39.011.9530135 Fax. : +39.011.9781115 Email: [EMAIL PROTECTED] WWW: http://www.acmeconsulting.it/
Re: squid-3 vs 2.6
Let's focus on rescuing 3.0 back to stable, so that developers prefer to develop on 3.x than 2.x On 25 Jun 2006, at 09:28, Henrik Nordstrom wrote: * Any release plans depending on forcing something to get done is a risky one. * Open Source development works by interest, not force. * The single thing holding Squid-3 back is the fact that it's not stable. Until Squid-3 is stable it's very hard to shift development over there, and even harder to draw customer attention. We are at the point where we need to stop being general, and start being very specific, about HOW Squid-3 is not stable. What are the measures of stability? How do we prove to each other that Squid-3 is stable or unstable? I expect the answer to be in two parts: 1. an empirical definition of stable. I.e. a way of testing that Squid-3 is *actually* stable (maybe running in production somewhere, or passing other tests that are currently failed) 2. a set of bugs in Bugzilla which, when fixed, should take us up to this standard My feeling is that we are close enough that our next PRE can take us within reach of RC1. At which point I shall fly to Stockholm, remove my trousers and dance around Sergels Torg. Doug
Re: squid-3 vs 2.6
On Sun, Jun 25, 2006, Doug Dixon wrote: We are at the point where we need to stop being general, and start being very specific, about HOW Squid-3 is not stable. What are the measures of stability? How do we prove to each other that Squid-3 is stable or unstable? IMHO we lost out because the scope of squid-3 became less and less abstract out the stuff that we're doing in Squid-2.5 that can be represented with a simple move to C++ classes and started on the path of rewriting large chunks of code. Its good that this has stopped. :) I expect the answer to be in two parts: 1. an empirical definition of stable. I.e. a way of testing that Squid-3 is *actually* stable (maybe running in production somewhere, or passing other tests that are currently failed) 2. a set of bugs in Bugzilla which, when fixed, should take us up to this standard 3. Don't change anything unless its directly related to making something stable; no matter how simple the change is. My feeling is that we are close enough that our next PRE can take us within reach of RC1. At which point I shall fly to Stockholm, remove my trousers and dance around Sergels Torg. I agree. Squid-3 is much more stable then it was a few months ago. Lets all learn from this for the next major squid rework. :) Adrian
Re: squid-3 vs 2.6
sön 2006-06-25 klockan 10:58 +0200 skrev Guido Serassio: You wrote The 2.6 release is actually about focusing the community again. This is happening because 2.6 include a lot of feature needed in real production environments, features already developed for 2.5 often with a customer sponsorship. But I'm not so sure that the current feature set of 3.0 could generate the same attention in the community: the general lack of sponsorship for the development of 3.0 features (with the exception of ESI and ICAP) is a worrying signal. And is why we must get a 3.0.STABLE out (in STABLE condition), so we can start shift production attention over there. It's the only way forward. Regards Henrik signature.asc Description: Detta är en digitalt signerad meddelandedel
Re: squid-3 vs 2.6
lör 2006-06-24 klockan 11:57 +1200 skrev Doug Dixon: You say relatively small - but with the potential to cause lots of instability. Yes, or at least so for three of them. collapsed_forwarding, ETag and connection pinning all introduces new internal states in the request processing, and all impacts the general request forwarding logics.. and the user perceived feature gains of these is fairly small. WCCPv2 is very isolated to itself. No issues there. TPROXY is quite isolated. Follow X-Forwarded-For looks relatively isolated, but perhaps not the correct approach to the problem.. Do you agree that most of these missing features would best be put in 3.1, after 3.0 has reached production stability? collapsed_forwarding, ETag, Connection pinning and Follow X-Forwarded-For is 3.1 candidates if you ask me. WCCPv2 and TPROXY can go in whenever they are in shape for Squid-3. Especially so WCCPv2. Perhaps the smaller and less risky ones might be acceptable into 3.0... but we must be very careful. Regarding new features in Squid-3 I think the devel.squid-cache.org model should now be followed quite strictly. 1. A new feature is developed in a floating branch using the vcs of choice (i.e. CVS with our scripts or Baz). 2. Any bug fixes or similar plumbing work done while implementing the new feature is trickled back into mainline. The branch should be kept clean with only the new feature. 3. When the new feature is ready and used in production it's announced as ready for merging, and placed in the merge queue with review etc.. This development model is what has made the 2.6 release possible in the short timeframe available. 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? We indeed need a more living homepage.. unfortunately none of the project members likes spending time with writing web pages.. Would everyone on this list support the following: 1. No more 2.x development - new features must be against 3.x Sorry, until Squid-3.0.STABLE is in such shape that it can run in production without the admins having to worry all night this won't happen. Even if we all promise. Simple fact of life.. But as soon as we get Squid-3 in production quality shape this should apply I think. 2. Release 3.0.STABLE as quickly as possible (stability is priority, still may lack features from 2.6) Yes. 3. Release 3.1 soon after that (feature complete, 2.6 is obsoleted) To be honest I think the two will coexists for some time. But Squid-3 will win over time. And I second the assessment that 3.0 is quite stable now. We should unite behind it! Not quite there yet I am afraid.. but it now has the potential to get there. Regards Henrik signature.asc Description: Detta är en digitalt signerad meddelandedel
Re: squid-3 vs 2.6
lör 2006-06-24 klockan 18:57 +0200 skrev Guido Serassio: Here I agree about the reasons, but I am doubtful about a 3.0 with not all the 2.6 features: It's a simple matter or project priorities. With no doubt the absolutely highest priority for Squid-3 must be get a stable release out as soon as possible. The more new features added the longer this will take. why someone will downgrade its proxy ? Why not? And if they don't want to they have the choice of making sure they don't need to. Why is Squid-3 completely outside it's original release plan, and still no-one knowing when it's reasonable to expect a stable release? Just for example: all my customers are waiting for connection pinning with open arms Then I am pretty sure at least one of them is willing to sponsor the development and bug fixing required to get that feature in squid-3, making it available as a patch to the Squid-3.0 release early on, and then merged into 3.1. Or if you prefer spending your time implementing the connection pinning for 3.0 instead of fixing bugs then you are very welcome to. When complete and tested in production it's a candidate for merging. If good it may make it into 3.0, else 3.1. I remember the proposal when 2.6 work was announced: 1) 3.0 initially mainly for high end reverse proxies (ICAP ESI) and 2.6 for forward proxies 2) 3.1 for both usage with all features. It seems to me a good compromise for a customer. I am not sure even 3.1 will be 100% feature complete. I don't think we as a team can bind to that promise as it's very dependent on what other tasks each of us take for the 3.1 release. The most important is that we make progress. If this means some features is deferred so be it. There is no sponsor behind this project who work on such generic scale as feature complete. Customers mostly pay for what they need, i.e. bug fixing of the issues they run into or features they need. Outside that we can not force anything on anyone else than yourself. * Any release plans depending on forcing something to get done is a risky one. * Open Source development works by interest, not force. * The single thing holding Squid-3 back is the fact that it's not stable. Until Squid-3 is stable it's very hard to shift development over there, and even harder to draw customer attention. Regards Henrik signature.asc Description: Detta är en digitalt signerad meddelandedel
Re: squid-3 vs 2.6
sön 2006-06-25 klockan 02:11 +1200 skrev Reuben Farrelly: With 3 or 4 branches on the go, there is a lot of potential for users to get confused by this and people to run code with possibly wrong expectations about what support they can expect. There should not be more than 3 branches. 2 STABLE in bug maintenance only mode, one DEVEL for new features. Then on the side there may be a number of new features developed to any combination of these depending on the situation. I also think we should decide at some point how and for how much longer we are going to support 2.5 and 2.6 in the absence of sponsorship, and announce a roadmap soon so that users have lots of warning of what is coming up. We don't want to end up with 2.5, 2.6 and 3.0 in a stable cycle with 3.1 in development all at the same time at the end of this year ;) Hopefully we have 2.6 and 3.0 in STABLE cycle, and 3.1 in development. 2.6 most likely stays in STABLE cycle for as long as there is significant features not yet in Squid-3. 2. For Squid-2.6, a tentative date on the lifespan of Squid-2.6 as being supported for 8-12 months after 2.6-STABLE1 release date which takes it through to March-July next year (maybe a bit longer if it's not much work to maintain and/or it flushes out bugs that we can also forward port easily in 3.0). I don't think we are in a situation to make any time related promises. Those have never worked out well in the past.. Once Squid-3 is out it should be the primary recommended version for use especially with any new installations and we should make sure that the wiki and website appropriately pushes people in that direction. Yes. Regards Henrik signature.asc Description: Detta är en digitalt signerad meddelandedel
Re: squid-3 vs 2.6
sön 2006-06-25 klockan 02:11 +1200 skrev Reuben Farrelly: I also think we should decide at some point how and for how much longer we are going to support 2.5 and 2.6 in the absence of sponsorship, and announce a roadmap soon so that users have lots of warning of what is coming up. We don't want to end up with 2.5, 2.6 and 3.0 in a stable cycle with 3.1 in development all at the same time at the end of this year ;) Well.. my support (i.e. bugfixing) for 2.5 is ending by the release of 2.6.STABLE1. This is how it has always been with Squid releases. Regards Henrik signature.asc Description: Detta är en digitalt signerad meddelandedel
Re: squid-3 vs 2.6
First thing's first... putting stuff in Bugzilla Missing features: - collapsed forwarding - WCCPv2 - TPROXY - Connection pinning for relaying of Microsoft Integrated Auth. - ETag - Follow X-Forwarded-For - anything else? These are all in Bugzilla now. Target Milestone is either 3.0 or 3.1 based on hno's recommendations in this thread 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 These are NOT in Bugzilla yet - could someone who knows more about these please add them? Thanks Doug
squid-3 vs 2.6
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. 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 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. Regards Henrik signature.asc Description: Detta är en digitalt signerad meddelandedel
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
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
