On tor, 2008-07-03 at 21:21 +1200, Amos Jeffries wrote: > Well... > > - these two in particular are binaries independent of the squid code. > They share only some portability objects.
squidclient got modified in squid-2 only because Squid gained new features (basic HTTP/1.1 support). Not forward ported as Squid-3 does not have this yet. I wasn't aware cachemgr had changes not yet in squid-3. What was missing? > - its bothersome to maintain two sets of duplicated code for an > indefinite period. From now on just yell at anyone who commits changes to those tools in Squid-2 without also making the change in Squid-3. > - when I'm done with them now, the Squid-3 code is either identical > (excluding whitespace formatting and comments) to the Squid-2-HEAD code. > Or at least have all the bug fixes and improvements made in 2.6/2.7 to > date underneath their Squid-3 fixes and polish. Good. > One of the project goals is to form a clear upgrade path from 2.x to > 3.x. These two tools have in my view now achieved that clear upgrade > path, with full backwardly compatible code in the Squid-3 VCS. Most people run only one or the other, bundled together. > So its time to consider their deprecation in the Squid-2 CVS before any > further changes get done. Why? It's not a big burden to keep them syncronized. > I've given this some further thought since my initial hurried email and > I think it would be easy enough for us to bundle the code for them > separately as a squid-tools package which happens to be built from the > Squid-3 bzr if we need to. The tools partially depend on Squid libraries. I don't think it's worth the effort to try separating out these tools. Additionally it won't really solve the problem, just move it around a little.. Better to spend effort on the "squid-2 forward port changesets repository" we talked about before, enabling us to keep close track of which squid-2 changesets should be forwardported. Regards Henrik
signature.asc
Description: This is a digitally signed message part
