On 1/26/23 04:12, Amos Jeffries wrote:
On 26/01/2023 3:30 am, Alex Rousskov wrote:
On 1/25/23 07:29, Amos Jeffries wrote:
On 25/01/2023 5:34 pm, Alex Rousskov wrote:
IMO, we should not keep any code that is only needed for Squid v3.1
and earlier. Squid v3.2 and later should http-based cache manager
access, right? More code always means more maintenance overheads and
higher change costs. Given our lack of resources, we should start
ignoring Squid v3 needs.
In sentiment I agree. In practicality we have to cope with "LTS" from
vendors, and Squid bugs in the manager.
IMO, LTS vendors and old Squid bugs do not prevent us from removing
cache_object support from cachemgr.cgi: The number of admins that
match _all_ of the conditions listed below at the same time is
negligible.
Evidence needed.
It would be nice to back up my reasoning with hard evidence, but I do
not think it is _required_ in this case. It is impractical to prove
negligibly low count of X when there is no way to enumerate all
instances where X might exist. These kind of decisions require a
judgement call.
Circumstantial evidence does exist -- the Project does not see a
constant stream of complaints, bug reports, and improvements related to
cachemgr.cgi despite its many shortcomings. We also do not see a lot of
complaints about v3.2 or a lot of examples where v3 users cannot
upgrade. To avoid misunderstanding, I am not claiming that evidence
proves my point beyond reasonable doubt. It is only partial and
circumstantial.
We should not spend our resources "coping" with those esoteric cases.
1. Use Squid v3.
2. Use Squid v7.
3. Use cachemgr.cgi to manage both Squid versions.
4. Cannot use cachemgr.cgi from Squid v6.
5. Cannot patch cachemgr.cgi v7 to restore cache_object support.
Declaring groups of users "negligible" or "esoteric" without evidence
just to push your preferred decision is not a valid line of argument.
First of all, I am not declaring groups of users "negligible" or
"esoteric". I am speculating about the number of certain use cases and
classifying those use cases.
I believe my line of argument is valid, even though it is not (and,
given existing Project limitations, cannot be) backed by hard evidence.
We will never know how many use cases match all 5 criteria. In fact, we
will never know how many Squid use cases are out there today!
If you have hard evidence that illustrates that relevant use cases are
common, please present it. Needless to say, I am not aware of such evidence.
v3.2 has http: but the https:, ftp:, whois:, gopher: schemes were
broken until late in the v3.5 series backports.
So going by [1] LTS systems still using v3.2 are still a pain.
We can stop that pain any time we want. All it takes is for us to stop
mentioning v3 releases when making design decisions like this one. We
_choose_ to prolong that pain and to spend scarce resources on a
negligible percentage of unimportant use cases instead of spending
those resources on popular and important use cases.
We are making decisions which affect other peoples lives and employment.
The "pain" I have been mentioning is _their_ pain, not ours.
When making a decision, we should take into account the "lives and
employment" and "pains" of all affected people. We cannot make everybody
happy, and if we try, we are likely to increase the overall level of
unhappiness. Making (few) v3 users happier at the expense of hurting
(many more) v5 users is the wrong balance IMO, and that is what we often
end up doing when it comes to this kind of decisions.
It is appropriate to keep the human aspect in mind for this decision and
utilize the data we do have available.
Agreed. That is exactly what I am doing.
That data I have says v3.2 and v3.5 are still relevant factors for this
change.
Their relevance is not being disputed. What we disagree on is whether
those (real) v3 user needs are enough to hurt other (also real) users.
The longer we wait on removal from the CGI and CLI tools (only) the
more seamless it goes. So I am inclined to be very conservative on
the tools capability removal and proactive on ensuring they can cope
with the squid capability loss.
And since there is no way to actually measure "more seamless" or to
prove that we are wasting resources on rare unimportant use cases, we
end up doing what we do best -- increasing and prolonging pain.
We do have at least one measure. I use the count of Vendors distributing
each problematic release.
Over time their old versions reach EOL, or LTS get updated to new Squid
versions etc.
We can reasonably expect admin to be using a currently supported version
of their OS packages.
The proposed measure is just too coarse to be applicable here because
the proposal does _not_ inconvenience users of problematic releases. In
fact, the proposal does _not_ inconvenience users of _any_ given Squid
release in existence! It only inconvenience users that match a long list
of very special criteria. For example, it requires a user to use _both_
v3 and v7 releases, at the same time.
Alex.
_______________________________________________
squid-dev mailing list
squid-dev@lists.squid-cache.org
http://lists.squid-cache.org/listinfo/squid-dev
