<div dir="ltr"><div dir="ltr">On Wed, Apr 28, 2021 at 11:34 PM Alex Rousskov <<a href="mailto:rousskov@measurement-factory.com" target="_blank">rousskov@measurement-factory.com</a>> wrote:<br></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On 4/28/21 5:12 PM, Amos Jeffries wrote:<br>
> I'm not sure why this is so controversial still. We have already been<br>
> over these and have a policy from last time:<br>
<br>
Apparently, the recollections of what was agreed upon, if anything,<br>
during that "last time" differ. If you can provide a pointer to that<br>
"last time" agreement, please do so.<br></blockquote><div><br></div><div>Merge workflows are agreed, and not in discussion. Recent discussions have highlighted some issues with what's around them, and I'm trying to clarify that as well</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">> * dev PR submissions use the volatile 5-pr-test, after test approval by<br>
> anyone in QA. Check against unstable OS nodes, as many as possible.<br>
> Kinkie adds/removes from that set as upgrades fix or break at CI end of<br>
> things.<br>
<br>
I do not know how to interpret the last sentence correctly, but, IMO, we<br>
should not add or change nodes if doing so breaks master tests. AFAICT<br>
from PR 806 discussion[1], Francesco thinks that it is not a big deal to<br>
do so. The current discussion is meant to resolve that disagreement.<br></blockquote><div><br></div><div>Let me highlight the underlying principles for my proposal: IMO our objectives are, in descending order of importance (all points should be intended "as possible given our resources"):</div><div>1. ensure we ship healthy code to a maximum number of users</div><div>2. have minimal friction in the development workflow<br></div><div><br></div><div>These objectives have a set of consequences:</div><div>- we want our QA environment to match what users will use. For this reason, it is not sensible that we just stop upgrading our QA nodes, or we would target something that doesn't match our users' experience<br></div><div>- it makes little sense to target unstable distributions (fedora rawhide, possibly centos stream, gentoo, opensuse tumbleweed, debian unstable) as first-class citizens of the testing workflow, especially on stages that are executed often (pr-test)</div><div><br></div><div>This means that:</div><div>- I periodically weed out distributions that are no longer supported (e.g. Fedora 31, Ubuntu Xenial) and add current distribution (e.g. Ubuntu Hirsute, Fedora 34).</div><div>I take it on me that when I do that, I need to ensure new compiler features do not block previously undetected behaviours - I am currently failing this, see <a href="https://build.squid-cache.org/job/trunk-matrix/121/" target="_blank">https://build.squid-cache.org/job/trunk-matrix/121/</a> . I will need to develop a process with a proper staging phase.</div><div></div><div>- I believe we should define four tiers of runtime environments, and reflect these in our test setup:</div><div> 1. current and stable (e.g. ubuntu-latest-lts). These are not expected to change much over a span of years, and to offer non-breaking updates over their lifetime</div><div> 2. current (e.g. fedora 34)</div><div> 3. bleeding edge: they may introduce breaking changes which it makes sense to follow because they might highlight real issues and because they will eventually trickle down to current and then lts</div><div> 4. everything else - this includes freebsd and openbsd (mostly due to the different virtualization tech they use)</div><div><br></div><div>I believe we should focus on the first two tiers for our merge workflow, but then expect devs to fix any breakages in the third and fourth tiers if caused by their PR, while I will care for any breakages caused by dist-upgrades</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
[1] <a href="https://github.com/squid-cache/squid/pull/806#issuecomment-827937563" rel="noreferrer" target="_blank">https://github.com/squid-cache/squid/pull/806#issuecomment-827937563</a><br>
<br>
<br>
> * anubis auto branch tested by curated set of LTS stable nodes only.<br>
<br>
FWIW, the above list and the original list by Francesco appears to focus<br>
on distro stability, popularity, and other factors that are largely<br>
irrelevant to the disagreement at hand. The disagreement is whether it<br>
is OK to break master (and, hence, all PR) tests by changing CI. It does<br>
not matter whether that CI change comes from an upgrade of an "LTS<br>
stable node", "unstable node", or some other source IMO. Breaking<br>
changes should not be allowed (in the CI environments under our<br>
control). If they slip through despite careful monitoring for change<br>
effects, the breaking CI changes should be reverted.<br></blockquote><div><br></div><div>I think it depends.</div><div>Breakages due to changes in nodes (e.g. introducing a new distro version) would be on me and would not stop the merge workflow.</div><div>What I would place on each individual dev is the case where a PR breaks something in the trunk-matrix,trunk-arm32-matrix, trunk-arm64-matrix, trunk-openbsd-matrix, trunk-freebsd-matrix builds, even if the 5-pr-test and 5-pr-auto builds fail to detect the breakage because it happens on a unstable or old platform. </div><div> </div></div>-- <br><div dir="ltr">    Francesco</div></div>