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
This archive was generated by hypermail 2.2.0 : Thu Jul 03 2008 - 12:00:03 MDT