Re: [squid-dev] What os/cpu platforms do we want to target as a project?
On 12/26/21 8:36 PM, Amos Jeffries wrote: > On 27/12/21 10:11, Alex Rousskov wrote: >> On 12/26/21 10:30 AM, Francesco Chemolli wrote: >>> On Sun, Dec 5, 2021 at 10:05 PM Alex Rousskov wrote: 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 >> My proposal is trying to solve the specific problem that recent PRs >> (attempting to remove some code) have faced: The reviewer asked _why_ we >> are removing code, and the author closed the PR instead of developing >> consensus regarding the correct answer to that question[1]. My proposal >> establishes a special track for code removal PRs so that they do not >> have to answer the (otherwise standard) "why" question. > [1] is about removal of a trivial piece of code that has no harm leaving > in place. > > As I stated in followup what I regard as reasonable justification *was* > given up front. If that was not enough for agreement to merge it was not > worth the jumping through hoops in the first place. Let alone creating a > whole new bureaucratic policy and management process. > > As I said in other discussions, we already have a deprecation+removal > process that works fine and matches the industry standard practices when > a code change is even suspected to matter to anyone at all. That process > gives far more than just 30 days to inform any interested community > members and does not limit the notification channels. > > If anyone picks up the code removal in [1] again they should follow that > process I do not think they should. IMO, that (poorly working) deprecation+removal process should not be used for explicit OSF/1 support removal (among other things). They should use the regular PR review process (if we do not come up with something better by then). > since that code is now obviously of some importance to reviewer Alex. FWIW, I still[2] support removal of explicit OSF/1 support. The reason we had this discussion is not some special importance of that explicit OSF/1 support code. The goal is to lower the overhead of future PRs similar to the one you closed _because_ that overhead was too high. Hope this clarifies, Alex. [1] https://github.com/squid-cache/squid/pull/942#issuecomment-986208860 [2] https://github.com/squid-cache/squid/pull/942#issuecomment-986055422 ___ squid-dev mailing list squid-dev@lists.squid-cache.org http://lists.squid-cache.org/listinfo/squid-dev
Re: [squid-dev] What os/cpu platforms do we want to target as a project?
On 12/27/21 4:41 AM, Francesco Chemolli wrote: > On Sun, Dec 26, 2021 at 10:58 PM Alex Rousskov 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 First of all, thank you for making good progress on this important thread. > 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 share the overall sentiment, but I think all of the above concerns can continue to be adequately addressed with FreeBSD/OpenBSD being assigned to the second tier (i.e. the "best-effort" tier you have proposed). IMO, it makes little sense to name two tiers and then essentially treat the second named tier as "all other". The second tier, as proposed, will bring our attention to any FreeBSD/OpenBSD regressions and, in most cases, we will address them (because they are usually easy to address). IMO, this level of support is more than adequate given our lack of resources and relative unpopularity of those platforms. Perhaps this difference in approaches is rooted in our current (and newly discovered!) disagreement on when best-effort/tier-2 results must be reported (as discussed further below). > 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. Same here: I share the sentiment but consider all these arguments appropriate for tier-2; they are an overkill for tier-1. Squid can survive without x86-32, arm32, MIPS, and RISC-V support. Yes, we do not want to accidentally abandon support for those environments, without a compelling reason, but that is exactly why we are adding tier-2 -- to eliminate such accidents: Thanks to tier-2 presence, the decision to regress support for those platforms (in some specific PR scope) will be deliberate, _not_ accidental. >>> 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]. >> [1] https://wiki.squid-cache.org/ReleaseSchedule Just to avoid misunderstanding, my comments/opinions about minor releases below apply to the text below. My sentence quoted above is not about minor releases; it is about major releases; major releases occur on a fixed schedule; they are not governed by release maintenance rules that are largely in Amos hands today. Moreover, since no PR can be merged if it breaks tier-1 support, it is impossible to have a tier-1 regression unless we change the test environment without fixing Squid first (which we should not do, especially for tier-1 platforms!). >> As for other/minor releases, I am not against this rule if the >> maintainer is happy about it. > Amos, what do you think? I would like to adjust my comment: I think this additional formal rule is not needed because we should just let the maintainer decide what maintenance rules work best (and adjust them as needed), but I am not against adding that formal rule if Amos wants to add it to his current set of rules. >> 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. The "I will eventually let you know if your old PR broke OpenBSD support and let you decide whether to revert that PR commit or fix the problem sometime in the future" approach does not work (and has never worked) well IMO. We should know about tier-2 regressions _before_ PR
Re: [squid-dev] What os/cpu platforms do we want to target as a project?
On Sun, Dec 26, 2021 at 10:58 PM Alex Rousskov 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
