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

Rebecca Cran rebecca at bsdio.com
Fri Jan 8 20:20:19 UTC 2021


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 at 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
>>
> 
> 
> 
> 
> 




-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#70073): https://edk2.groups.io/g/devel/message/70073
Mute This Topic: https://groups.io/mt/79119037/1813853
Group Owner: devel+owner at edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [edk2-devel-archive at redhat.com]
-=-=-=-=-=-=-=-=-=-=-=-





More information about the edk2-devel-archive mailing list