From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [63.128.21.124]) by mx.groups.io with SMTP id smtpd.web09.89.1610130892436961824 for ; Fri, 08 Jan 2021 10:34:52 -0800 Authentication-Results: mx.groups.io; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=M+yCwFtL; spf=pass (domain: redhat.com, ip: 63.128.21.124, mailfrom: lersek@redhat.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1610130891; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=Br1BzxiGpS5Lcgb7mrEbQgrrtoIfSHrxbkwKNQb6VZs=; b=M+yCwFtLsb6ELph8Y6jhMfNVieCQOHX79Gp9DzUalDHSTRtZVcg9ydCf4Ueu/VS2fTmbZ0 wWPIEYyCX8zBWlylNJ0A8gR4TCcuM8yOaWf+fOAQnv8KiiWbQba2T3QXgpUBDTnDwwksG+ I8t6TgOgwCZ4d7+SZ4P9i8PSnXRURQc= Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-32-rcCFPq91NlyHbybzZenEjA-1; Fri, 08 Jan 2021 13:34:48 -0500 X-MC-Unique: rcCFPq91NlyHbybzZenEjA-1 Received: from smtp.corp.redhat.com (int-mx03.intmail.prod.int.phx2.redhat.com [10.5.11.13]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 7790A10054FF; Fri, 8 Jan 2021 18:34:46 +0000 (UTC) Received: from lacos-laptop-7.usersys.redhat.com (ovpn-113-112.ams2.redhat.com [10.36.113.112]) by smtp.corp.redhat.com (Postfix) with ESMTP id 8EF2E614EF; Fri, 8 Jan 2021 18:34:44 +0000 (UTC) Subject: Re: [edk2-devel] [Patch 1/1] EmulatorPkg/PlatformCI: stick with "ubuntu-18.04" for now To: Rebecca Cran , devel@edk2.groups.io, spbrogan@outlook.com, bob.c.feng@intel.com Cc: Jordan Justen , Andrew Fish , Ray Ni , Michael Kinney References: <20201221031930.1799-1-bob.c.feng@intel.com> <1ceee144-3cd0-8991-a381-e368ed4245ef@redhat.com> <05cac02b-c2e3-8cef-8795-59ce6d2a1c71@bsdio.com> From: "Laszlo Ersek" Message-ID: <20fb818b-ddb2-54ee-50b1-c22baa878bed@redhat.com> Date: Fri, 8 Jan 2021 19:34:43 +0100 MIME-Version: 1.0 In-Reply-To: <05cac02b-c2e3-8cef-8795-59ce6d2a1c71@bsdio.com> X-Scanned-By: MIMEDefang 2.79 on 10.5.11.13 Authentication-Results: relay.mimecast.com; auth=pass smtp.auth=CUSA124A263 smtp.mailfrom=lersek@redhat.com X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit 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