[squid-dev] Strategy about build farm nodes
Alex Rousskov
rousskov at measurement-factory.com
Wed Apr 28 21:34:43 UTC 2021
On 4/28/21 5:12 PM, Amos Jeffries wrote:
> I'm not sure why this is so controversial still. We have already been
> over these and have a policy from last time:
Apparently, the recollections of what was agreed upon, if anything,
during that "last time" differ. If you can provide a pointer to that
"last time" agreement, please do so.
> * dev PR submissions use the volatile 5-pr-test, after test approval by
> anyone in QA. Check against unstable OS nodes, as many as possible.
> Kinkie adds/removes from that set as upgrades fix or break at CI end of
> things.
I do not know how to interpret the last sentence correctly, but, IMO, we
should not add or change nodes if doing so breaks master tests. AFAICT
from PR 806 discussion[1], Francesco thinks that it is not a big deal to
do so. The current discussion is meant to resolve that disagreement.
[1] https://github.com/squid-cache/squid/pull/806#issuecomment-827937563
> * anubis auto branch tested by curated set of LTS stable nodes only.
FWIW, the above list and the original list by Francesco appears to focus
on distro stability, popularity, and other factors that are largely
irrelevant to the disagreement at hand. The disagreement is whether it
is OK to break master (and, hence, all PR) tests by changing CI. It does
not matter whether that CI change comes from an upgrade of an "LTS
stable node", "unstable node", or some other source IMO. Breaking
changes should not be allowed (in the CI environments under our
control). If they slip through despite careful monitoring for change
effects, the breaking CI changes should be reverted.
Alex.
More information about the squid-dev
mailing list