— 

Rebeca Cran 

On 01/08/21 19:14, Rebecca Cran wrote:

On 1/8/21 11:01 AM, Sean wrote:

Question to the community (especially those using a Linux environment)

is what priority should it be to go resolve these and update CI to run

on Ubuntu 20.04?  General premise is we should stay current without

being bleeding edge but I want to understand other perspectives.

From previous discussions, it sounds like we did want to be on the

bleeding edge - which I personally think is a bad idea, since breaking

changes can come in at the worst time.

Instead, we should stay on a stable release but watch out for newer

versions and move forward to them after applying any fixes.

I'm all for sticking with stable artifacts, but:

- we don't know *how long* the github.com/actions organization intends
to support the 18.04 LTS image

- the breakage with 20.04 LTS indeed hit us at a bad time, but at least
we had something to fall back to. If we switch to the oldest supported
VM image, as a permanent choice, then, when that image loses support,
we'll only be able to escape *forward* -- and *that* is an even worse
experience.

It's always the same problem -- production users always want *someone
else* to test out the new release for them.

Instead, what I would really welcome here is if we exempted edk2 patches
that tweaked the CI configuration from the usual patch review process.
Delaying an actual edk2 patch because its review is not complete --
that's fine, that's how development works. On the other hand, blocking
the *merging* of an otherwise reviewed patch, just because the CI system
is broken again, is an *outrage*. Having to submit *further patches to
review* -- this time for the CI config itself --, in order to mitigate
the CI breakage, is a completely broken workflow.

Laszlo