> I would recommend upgrading the Squid cluster because it's run on a > very significantly old version of the software, lacks several years > worth of general patches and maintenance, and because it's not THAT > big a deal. As I mentioned earlier in thread, I spent several years > running Squid (at the time, 3.0-stablevarious and 3.1 beta tests) at a > large site, and it didn't take that much time and effort despite > working actively with Amos and others on what turned out to be an > uninitialized buffer problem for over a year and having to compile, > tune, and seriously test all the versions from 3.0-STABLE3 through ... > 19, it looks like. It was perhaps 20% of my total work for about 3 > years, and would have been far less had it not been for the one > persistent bug (going from the prior 2.6 squids to 3.0 took about 3 > months of me 1/4 time-ish). Performance was noticeably better with > 3.0 vs 2.6 and 2.7. >
Well, by all means, add our patches in to the newer version, and provide a source package. > Avoidance of obsolete version software rot is a key operations > technique. My current main commercial consulting customer has 5 > years-past-end-of-support key enterprise infrastructure software that > they don't even quite know how to upgrade, it's so old now. Don't let > your versions get that old... > > Yes, 2.7 is still getting necessary Squid project patches, latest to > STABLE9 in March 2010, but still. It's old 8-) > Our plan is to eventually move away from squid and to varnish. Upgrading squid really isn't amazingly high on our priority list right now. Respectfully, Ryan Lane _______________________________________________ Wikitech-l mailing list [email protected] https://lists.wikimedia.org/mailman/listinfo/wikitech-l
