[squid-dev] What os/cpu platforms do we want to target as a project?

[Alex Rousskov]

On 12/5/21 4:44 AM, Francesco Chemolli wrote:

> I would recommend that we support as main targets:
> - Linux on x64, arm64, arm32 and, if we can, MIPS
> - FreeBSD, OpenBSD on x64

> As best-effort:
> - Windows on x64, with the aim of eventually promoting to primary target
> - Darwin on x64 and maybe eventually arm64
> - NetBSD on x64

What does "support as main targets" and "support as best-effort" mean?

Without defining/detailing these two terms, it is impossible to properly
evaluate this proposal IMO...


> If anyone in the community wants to support/maintain extra OSes or
> architectures, they're very welcome to do so

By "welcome", do you mean something like "we will accept high-quality
PRs adding such extra support to Squid"? Or "we will consider sharing
references to your work, but please do not ask us to merge your
OS-specific changes into the official Squid code"? Something else? This
bit is critical for understanding the real effect of this proposal IMO.

----

If we manage to and agree on what platforms to "support" and on removing
code dedicated to unsupported platforms, great! If we fail, I would like
to propose an alternative scheme for the removal of platform-specific
(or any other) code from the official master branch:

A PR dedicated to code removal can be merged if it satisfies the
following criteria:

1. Two positive votes from core developers.
2. No negative votes.
3. Voting lasted for 30+ calendar days.
4. The removal PR is announced in a PR-dedicated squid-users post.
   This announcement resets the 30+ day timer.

The author and reviewers do not have to justify the removal and the
votes if the PR author elects to use this special code removal
procedure. We simply trust they have good reasons to remove, support
removal, or block it.

A PR that does not satisfy the above criteria may still be merged under
the existing/regular PR merging rules. This special procedure does not
change those primary rules. It simply grants us the ability to avoid
difficult justifications and associated policy discussions in exchange
for longer wait times and more votes/exposure, under the assumption that
when it comes to simple removal, we just want to avoid (to the extent
possible) removing something that is still in significant use.

I am not sure we need rule #4, but it is not very difficult to post a
GitHub link and a PR description to squid-users, so the extra protection
that rule offers may be worth the posting overheads.

I am OK with increasing the 30 day waiting period if others think we
should wait longer for possible objections.


Thank you,

Alex.