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

[Alex Rousskov]

On 12/26/21 10:30 AM, Francesco Chemolli wrote:
> On Sun, Dec 5, 2021 at 10:05 PM Alex Rousskov wrote:
>> 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?

> "main targets" to me means that any regression in build or unit tests
> on these platforms is PR-blocking. We aim to deliver a working build
> out of the box on these environments, with no need of maintainer
> patches.

I am OK with that definition if you remove "in build or unit tests". Any
known Squid regression affecting the "main" environment should block the
PR introducing that regression IMO. I see no need to limit this to
"build and unit tests" regressions. Are you OK with that definition
simplification?

I do not think MIPS, FreeBSD, and OpenBSD should be on the "main" list:
There are just too few users and contributors on those platforms right
now to grant them primary status AFAICT. I may be missing some important
signals, of course, but I would downgrade them to best-effort.

I am not sure about arm32, for similar reasons, but perhaps there is a
strong demand for "embedded" Squid that I do not know about (and that
does not materialize in a stream of PRs because Squid already works well
in those environments??)? How can we tell?


> Once achieved this status on any of these platforms,
> regressions on it are release blockers.

I do not know what you mean by "release" exactly, but we should not add
rules that block schedule-based branching points and major releases[1].
As for other/minor releases, I am not against this rule if the
maintainer is happy about it.

[1] https://wiki.squid-cache.org/ReleaseSchedule



> "support as best effort" means that we keep these environment as build
> options, and test builds on them. Regressions on build or unit tests
> on these environments are not PR-blocking but we strongly encourage
> the PR owner to fix these platforms with followup PRs. We aim to
> deliver an out-of-the-box build on these platforms but failure to do
> so or regressions are not a release blocker

OK. If we drop the vague parts, "best effort" simply means that CI
covers these platforms (but they are not "main" environments and, hence,
the corresponding CI failures alone are not sufficient to block PRs).

AFAICT, the primary costs of keeping a platform on a best-effort list
are CI testing time and CI maintenance overheads. I suggest capping that
best-effort list to keep the total CI test time for one PR commit under,
say, 4 hours and granting CI maintenance team a veto on adding (but not
removing) platforms. IIRC, we have discussed PR commit testing time a
few months ago; if we agreed on another number of hours there, let's
take that as a cap.


>>> 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.
> 
> Fair point. I'd go for the former. If someone has an environment they
> want to support and do so without adding complexity to the code base,
> it's a good policy to enable that. The question is "how much
> complexity is it healthy to impose on other platforms to support
> niche/obsolete ones?"
> While setting an objective bar is hard to impossible, this is my
> attempt to set one for the most active group of developers

I agree regarding the level of difficulty in defining that bar.

Unfortunately, I do not think "we will accept high-quality PRs adding
such extra support to Squid" is something we should run with. We simply
do not have the resources to support some new environments, even if PRs
introducing them are perfect in every respect. For example, a perfect PR
introducing (explicit) LibreSSL support should be blocked IMO because we
do not have enough resources to properly handle the two already
(unfortunately) accepted TLS libraries (OpenSSL and GnuTLS).

However, we can drop this part of your proposal in hope to get to the
consensus on the other, arguably more important parts: The definitions
of three support levels (main, best-effort, and other). We can come back
to this part of the discussion later/separately, armed with established
and tested support levels.


Cheers,

Alex.