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

[Francesco Chemolli]

On Sun, Dec 26, 2021 at 10:58 PM Alex Rousskov
<rousskov at measurement-factory.com> wrote:
>
> 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?

Yes

> 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'm okay with downgrading MIPS - it is present in the embedded space
but testing poses some challenges.
I'm a bit more reluctant with downgrading FreeBSD and (once stable)
OpenBSD. They ship Squid as part of their ports, and while the
developer community may not be very large, I'd expect the user
community to be a bit more prevalent. This would also prevent the risk
of the project becoming a Linux monoculture.

> 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?

We can't, we have to guess. My angle on that is that having arm32 will
help us not become a 64-bit monoculture, which could bring in
regressions in low-level data structures. At this stage in the
embedded world, as far as I'm aware, there are x86-32, arm32, MIPS and
RISC-V. Of these arm32 is the most prevalent and therefore my
preferred choice. It also helps that we have a test environment for it
already, courtesy of a couple of raspberry pi 3.

> > 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.

Amos, what do you think?

>
> [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).

Sounds good

> 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.

The best-effort model supports testing best-effort platforms
asynchronously, no need to cap there. Regressions would be noted and
hopefully dealt with in followup PRs. We are already using this
practice.

> >>> 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.

Sounds like a good plan to me


-- 
    Francesco