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

[Francesco Chemolli]

On Sun, Dec 5, 2021 at 10:05 PM Alex Rousskov
<rousskov at measurement-factory.com> 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?
>
> Without defining/detailing these two terms, it is impossible to properly
> evaluate this proposal IMO...

That's a very fair point.
"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. Once achieved this status on any of these platforms,
regressions on it are release blockers.
"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


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

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

How about instead something along the lines of:
1. announce on squid-users about intent to remove support for a platform
2. wait for objections for 15 days
3. PR following standard merge procedure

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

My proposal doesn't change the merge process at all, it mostly gives
any active users in the candidate for removal a chance to speak up. I
think 15 days are a good window to not stall development too long, but
it can be extended if others feel we should


-- 
    Francesco