Re: [edk2-devel] [Patch 1/1] EmulatorPkg/PlatformCI: stick with "ubuntu-18.04" for now

["Rebecca Cran" <rebecca@bsdio.com>]

Well, at least Github have said they will only support LTS versions, so 
we'll only run into problems every couple of years with ubuntu-latest.

-- 
Rebecca Cran

On 1/8/21 11:54 AM, Rebecca Cran wrote:
> Given they still support Ubuntu 16.04 
> (https://github.com/actions/virtual-environments 
> <https://github.com/actions/virtual-environments>), I suspect 18.04 will 
> be supported until the upstream EOL in 2023.
> 
> —
> Rebeca Cran
> 
>> On Jan 8, 2021, at 11:35 AM, Laszlo Ersek <lersek@redhat.com> wrote:
>>
>> 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
>>
> 
> 
> 
> 
>