From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from out01.mta.xmission.com (out01.mta.xmission.com [166.70.13.231]) by mx.groups.io with SMTP id smtpd.web11.473.1610132101997480033 for ; Fri, 08 Jan 2021 10:55:02 -0800 Authentication-Results: mx.groups.io; dkim=pass header.i=@bsdio.com header.s=xmission header.b=BltNcpfz; spf=none, err=SPF record not found (domain: bsdio.com, ip: 166.70.13.231, mailfrom: rebecca@bsdio.com) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=simple/simple; d=bsdio.com; s=xmission; h=Subject:To:In-Reply-To:Cc:References:Message-Id:Date: Mime-Version:From:Content-Transfer-Encoding:Content-Type:Sender:Reply-To: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=pFmL8Ci4grPPqBwELnM3gxDTePLKaUxHNucEXxwO8PA=; b=BltNcpfzFxo1CiB8cF/Caw1OQ5 pEAZalh3E83ee/PTzdfvLGE4J2CMT11CDby2IZsx8Rm2fRBJ3lgpOv3J1im9YnFoQACukkHSx+2nP ICkKdaqoAbHSp6kW6Wqw7mTc2kSLwwsbBdCs/429KfA/bufZooMtsie4YxggAc6FiYWc=; Received: from in02.mta.xmission.com ([166.70.13.52]) by out01.mta.xmission.com with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.93) (envelope-from ) id 1kxwua-001I4Q-NY; Fri, 08 Jan 2021 11:55:00 -0700 Received: from mta4.zcs.xmission.com ([166.70.13.68]) by in02.mta.xmission.com with esmtps (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.93) (envelope-from ) id 1kxwuZ-00DffV-KQ; Fri, 08 Jan 2021 11:55:00 -0700 Received: from localhost (localhost [127.0.0.1]) by mta4.zcs.xmission.com (Postfix) with ESMTP id 6771A501074; Fri, 8 Jan 2021 11:54:59 -0700 (MST) X-Amavis-Modified: Mail body modified (using disclaimer) - mta4.zcs.xmission.com Received: from mta4.zcs.xmission.com ([127.0.0.1]) by localhost (mta4.zcs.xmission.com [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id mKgWe-COP6mn; Fri, 8 Jan 2021 11:54:59 -0700 (MST) Received: from [10.0.10.114] (c-174-52-16-57.hsd1.ut.comcast.net [174.52.16.57]) by mta4.zcs.xmission.com (Postfix) with ESMTPSA id 365FC5011FB; Fri, 8 Jan 2021 11:54:59 -0700 (MST) From: "Rebecca Cran" Mime-Version: 1.0 (1.0) Date: Fri, 8 Jan 2021 11:54:58 -0700 Message-Id: <0969A633-BBB9-4664-A90D-7AA45324554E@bsdio.com> References: <20fb818b-ddb2-54ee-50b1-c22baa878bed@redhat.com> Cc: devel@edk2.groups.io, spbrogan@outlook.com, bob.c.feng@intel.com, Jordan Justen , Andrew Fish , Ray Ni , Michael Kinney In-Reply-To: <20fb818b-ddb2-54ee-50b1-c22baa878bed@redhat.com> To: Laszlo Ersek X-Mailer: iPhone Mail (18C66) X-XM-SPF: eid=1kxwuZ-00DffV-KQ;;;mid=<0969A633-BBB9-4664-A90D-7AA45324554E@bsdio.com>;;;hst=in02.mta.xmission.com;;;ip=166.70.13.68;;;frm=rebecca@bsdio.com;;;spf=none X-SA-Exim-Connect-IP: 166.70.13.68 X-SA-Exim-Mail-From: rebecca@bsdio.com X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on sa01.xmission.com X-Spam-Level: ** X-Spam-Status: No, score=2.0 required=8.0 tests=ALL_TRUSTED,BAYES_50, DCC_CHECK_NEGATIVE,HTML_MESSAGE,MIME_QP_LONG_LINE, T_TM2_M_HEADER_IN_MSG,T_TooManySym_01,T_TooManySym_02,XMNoVowels, XMSubLong,XM_B_Unicode autolearn=disabled version=3.4.2 X-Spam-Virus: No X-Spam-Report: * -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP * 0.8 BAYES_50 BODY: Bayes spam probability is 40 to 60% * [score: 0.5000] * 0.7 XMSubLong Long Subject * 1.5 XMNoVowels Alpha-numberic number with no vowels * 0.0 XM_B_Unicode BODY: Testing for specific types of unicode * 0.0 T_TM2_M_HEADER_IN_MSG BODY: No description available. * 0.0 HTML_MESSAGE BODY: HTML included in message * 0.0 MIME_QP_LONG_LINE RAW: Quoted-printable line longer than 76 * chars * -0.0 DCC_CHECK_NEGATIVE Not listed in DCC * [sa01 1397; IP=ok Body=1 Fuz1=1] [Fuz2=1] * 0.0 T_TooManySym_02 5+ unique symbols in subject * 0.0 T_TooManySym_01 4+ unique symbols in subject X-Spam-DCC: XMission; sa01 1397; IP=ok Body=1 Fuz1=1 Fuz2=1 X-Spam-Combo: **;Laszlo Ersek X-Spam-Relay-Country: X-Spam-Timing: total 499 ms - load_scoreonly_sql: 0.02 (0.0%), signal_user_changed: 3.2 (0.6%), b_tie_ro: 2.2 (0.4%), parse: 0.86 (0.2%), extract_message_metadata: 10 (2.0%), get_uri_detail_list: 2.6 (0.5%), tests_pri_-1000: 2.0 (0.4%), tests_pri_-950: 1.10 (0.2%), tests_pri_-900: 0.84 (0.2%), tests_pri_-90: 54 (10.8%), check_bayes: 53 (10.5%), b_tokenize: 8 (1.6%), b_tok_get_all: 6 (1.2%), b_comp_prob: 2.1 (0.4%), b_tok_touch_all: 34 (6.8%), b_finish: 0.74 (0.1%), tests_pri_0: 417 (83.6%), check_dkim_signature: 0.46 (0.1%), check_dkim_adsp: 38 (7.7%), poll_dns_idle: 34 (6.8%), tests_pri_10: 1.72 (0.3%), tests_pri_500: 6 (1.1%), rewrite_mail: 0.00 (0.0%) Subject: Re: [edk2-devel] [Patch 1/1] EmulatorPkg/PlatformCI: stick with "ubuntu-18.04" for now X-SA-Exim-Version: 4.2.1 (built Sat, 08 Feb 2020 21:53:50 +0000) X-SA-Exim-Scanned: Yes (on in02.mta.xmission.com) Content-Type: multipart/alternative; boundary=Apple-Mail-16BC447F-DBC0-4E66-85A4-182A1132E8AA Content-Transfer-Encoding: 7bit --Apple-Mail-16BC447F-DBC0-4E66-85A4-182A1132E8AA Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Given they still support Ubuntu 16.04 (https://github.com/actions/virtual-en= vironments), I suspect 18.04 will be supported until the upstream EOL in 202= 3. =E2=80=94=20 Rebeca Cran=20 > On Jan 8, 2021, at 11:35 AM, Laszlo Ersek wrote: >=20 > =EF=BB=BFOn 01/08/21 19:14, Rebecca Cran wrote: >>> On 1/8/21 11:01 AM, Sean wrote: >>>=20 >>> 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. >>=20 >> =46rom 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. >>=20 >> Instead, we should stay on a stable release but watch out for newer >> versions and move forward to them after applying any fixes. >>=20 >=20 > I'm all for sticking with stable artifacts, but: >=20 > - we don't know *how long* the github.com/actions organization intends > to support the 18.04 LTS image >=20 > - 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. >=20 > It's always the same problem -- production users always want *someone > else* to test out the new release for them. >=20 > 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. >=20 > Laszlo >=20 --Apple-Mail-16BC447F-DBC0-4E66-85A4-182A1132E8AA Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable Given they still support Ubuntu 16.04 (https://github.com/a= ctions/virtual-environments), I suspect 18.04 will be supported until th= e upstream EOL in 2023.

=E2=80=94 
Rebeca C= ran 

On Jan 8, 2021, a= t 11:35 AM, Laszlo Ersek <lersek@redhat.com> wrote:

=EF=BB=BFOn 01/08/2= 1 19:14, Rebecca Cran wrote:
On 1/= 8/21 11:01 AM, Sean wrote:
=
Question to the community (especially those using a Linux enviro= nment)
is what priority should it be to go resolve these a= nd 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.

=46rom previous discussions, it sounds like we did want to be o= n 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 organi= zation 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 switc= h to the oldest supported
VM image, as a permanent choice, t= hen, when that image loses support,
we'll only be able to es= cape *forward* -- and *that* is an even worse
experience.

It's always the same problem -- production us= ers always want *someone
else* to test out the new release f= or them.

Instead, what I would really welco= me here is if we exempted edk2 patches
that tweaked the CI c= onfiguration from the usual patch review process.
Delaying a= n actual edk2 patch because its review is not complete --
th= at's fine, that's how development works. On the other hand, blocking<= br>the *merging* of an otherwise reviewed patch, just because the CI s= ystem
is broken again, is an *outrage*. Having to submit *fu= rther patches to
review* -- this time for the CI config itse= lf --, in order to mitigate
the CI breakage, is a completely= broken workflow.

Laszlo


=
= = --Apple-Mail-16BC447F-DBC0-4E66-85A4-182A1132E8AA--