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. _______________________________________________ squid-dev mailing list squid-dev@lists.squid-cache.org http://lists.squid-cache.org/listinfo/squid-dev
