Remove OSF/1 support

[yadij]

The last version of OSF/1 was released in 2012 under the name
Tru64 Unix for MIPS architecture CPUs. Its long-term support
by HP will be over by the time Squid-6 is released.

[rousskov]

It is not clear why we are removing this code. The PR description implies that this code is removed because OSF/1 "will no longer be supported" but it is not clear whether that phrase is talking about support by OSF Project, Squid Project, or somebody else. Please rephrase to clarify that.

Assuming we are talking about support by the Squid Project here: It is not clear what "support" actually means, why we decided (or will decide) to stop supporting OSF/1, and why that means we should remove this code. As you know, we have already tried but failed to answer very similar questions about the meaning of "support" this year. IMO, we should not be using the undefined term "support" to justify code changes until we succeed.

and will no longer be supported by the time Squid-6 is released

I do not think OSF is (or should be) "supported" by the Squid Project now, so I would prefer that we do not imply otherwise in the PR description, but I do not insist on the wording change to remove that implication.

To avoid misunderstanding, I am not trying to block removal of this code. I just want us to be clear why we are removing it.

[rousskov]

Thank you for updating the PR description and addressing one of my concerns. It is now clear that HP is expected to end their OSF/1 support by the time we expect Squid v6 to be released. This is good progress.

FWIW, it is still not clear why this code is being removed from Squid. Does this PR imply that the Squid Project would like to remove environment-specific code for all environments that are not longer supported by their stewards? Because "less code" is overall better? Or is there some other, perhaps more specific, motivation here?

I just want us to be clear why we are removing this code, especially since this PR can be viewed as setting precedence for other similar code removal...

And another/unrelated suggestion: If we are not sure that these code changes will make Squid unusable on OSF/1, then perhaps we can change "support" to "explicit support" in the PR title?

[yadij]

Withdrawing the attempt to remove this code since there seems to still be a very high bar to justify its removal.

[kinkie]

FTR, I support removing support for OSF/1
If anything, in the name of simplification, given that the expected userbase is - frankly speaking - nil.

As a matter of supported platform, I am willing to bet that the number of platforms it makes sense for Squid to explicitly support to be limited; in order of descending relevance:

• Linux on x64
• Linux on arm64
• Linux on arm32
• FreeBSD on x64
• OpenBSD on x64
• Windows on x64
• Darwin on x64
• Darwin on arm64
• NetBSD on x64
• AIX on Power

I expect the users of some of these to be already counted in the single digits worldwide; if they (and others who fell off the list) are motivated enough they can provide PRs to support their environment. Any level of code complexity to support anyone in the list is IMO not warranted

[rousskov]

FWIW, I also support removing OSF/1-specific code. I disagree with the unilateral decision to close this PR and with the rationale behind that decision.

the number of platforms it makes sense for Squid to explicitly support to be limited [to these specific platforms?] ...

I would like us to agree on a set of principles behind that (or any similar) list. You may be trying to formulate such principles after giving the list, so I will switch to that attempt without discussing any specific list entries (for now):

I expect the users of some of these to be already counted in the single digits worldwide. Any level of code complexity to support anyone in the list is IMO not warranted

Given the "any" in the second half, I see a single criteria in the above statement:

• The number of expected users is less than ten.

I think that is a good starting point. We may want to define "user" or switch from "users" to something like "independent or uncoordinated deployments", but I am more worried about two related high-level problems:

1. We do not have a good way of counting users/deployments/etc., especially when there are very few of them. We may be able to agree on how to confirm (lack of) usage, but such confirmations will take time, and that agreement is necessary before this rule can be adopted. Alternatively, we need to switch from "few expected users" to something that can be established/verified immediately (e.g., "no recent mailing list posts, bug reports, or official PRs" or even "no recent use cases known to PR reviewers" where "recent" is defined as "during the preceding 1000 calendar days" or some such).

2. We need an escape mechanism for special cases. For example, imagine that some feature (including platform support) is used by a single user and that user is contributing a lot to the Squid Project (beyond that special feature). We probably should not remove that feature for minor code simplification reasons, even though the feature has only one user behind it. Your "they can provide PRs to support their environment" thought can be viewed as an attempt to deal with similar situations, but it is not clear to me what that "environment supporting" PR would do to change the situation. It does not make sense for "them" to simply post a PR reverting the removal changes -- there would still be one or few users that need that feature, so it may be immediately removed again.

I can propose specific solutions to these problems, but I am worried about wasting time on a yet another attempt to define "support" because there seems to be no consensus that we need to define such things and/or to carefully justify our feature removal PRs.

[yadij]

The main reason for this PR is only "because we want to" - which is not worthwhile. What I wrote for description is the reasonable part of the justification for removal. If that is not enough for reviewers, then removal is not justified. Especially since this OS has a relatively modern release still under long-term vendor support.

I closed because this discussion about precise wording of the description is taking up way more of our time and resources than we gain from removing any of these old OS.

[rousskov]

The main reason for this PR is only "because we want to" - which is not worthwhile.

I do not know what you mean by "not worthwhile", but I think it can be a valid reason. In fact, I suspect that, with some tuning, it can become the best removal justification scheme for the Project. I will followup regarding that on squid-dev -- thank you, @kinkie, for starting that thread.

[rousskov]

I think ["because we want to"] can be a valid reason. In fact, I suspect that, with some tuning, it can become the best removal justification scheme for the Project. I will followup regarding that on squid-dev

Done in the second half of my squid-dev post.