From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from NAM11-DM6-obe.outbound.protection.outlook.com (NAM11-DM6-obe.outbound.protection.outlook.com [40.107.223.117]) by mx.groups.io with SMTP id smtpd.web12.585.1608059182891724658 for ; Tue, 15 Dec 2020 11:06:23 -0800 Authentication-Results: mx.groups.io; dkim=pass header.i=@microsoft.com header.s=selector2 header.b=Pc6NvRut; spf=pass (domain: microsoft.com, ip: 40.107.223.117, mailfrom: bret.barkelew@microsoft.com) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=D9Gd+Cq2a2u7myzYdegxFLO95OtSNBEyKN03cUwCnSD5PDVjmr5bhhpLWzM6Cy92+9lJXOteVnsMFVYqN1zxlPZ1CEHeJT2LuG9h8HfyUUp7cTCbTMvftsWW360lQQZtLOH1pz60tp6oD9fd7w1D5ayXDQRi2GRodkRuiKs4nMCUOomFUgisnQWpkPplFGWkDF6UQfr4WU1THYjnMVTwBufFQAkou31/FUOYZzO8cVuVtEy5taYFf197O9mSkdtHsW9EYvD4fzJdy8afdhwAqNxaEcrq2NyB8WcOTJ7gKA77kSXDkROiwowTS2UKnRZBHXGQSoXRAVCN4/E3PXuAtQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=PvdtbLFYp96TpXeIfketzJYHhd+yB4niCQSqypLhRZg=; b=VrfGA6Yh3KNHDd44oPiGA5azzD6Y8sd1qmyH7BxpenWvgfBElLyLiwnB/LMpfu+JsWssTYtRukes8DC4t5xA89C6BEigy+mdNroV5SSceU3sybANU0nBIiHJDl/+oRYE/DT/uInC294cg2wz7ZNZF/UKRf3RdWoHljWjOGyYABjZnhpQk+XFOD2HkFEi2U41FoJ3HrPKnRNpZ0Rm99VHo7AZz3n6VGh92pBoE4cVLJzj2jzLGAM3m16LR4yh1qqg6N44v0sc5Lkynd56VdEfXGUTwRbvdNpMrgqflOYOVSJqBrKn52YmYdM+OAa0ZEORKfKoYzU4oTMLb04gwsVfOQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=microsoft.com; dmarc=pass action=none header.from=microsoft.com; dkim=pass header.d=microsoft.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=PvdtbLFYp96TpXeIfketzJYHhd+yB4niCQSqypLhRZg=; b=Pc6NvRutfeceUTNXFT1shy5JexcNXjIqnLKR3McXXLGjRPPLGrOGsUgl9A300V9RIIhsF9DUmUnxryT3guBcYFoxAjQ35bcb4Jq+x1AilZv175l7Ju2kVOOmYj2oY1CWS4Y5nyMDRqQscsGnB6aDOEgks3/xIAMZb5bLUPvRpNg= Received: from (2603:10b6:300:78::18) by MW2PR2101MB1100.namprd21.prod.outlook.com (2603:10b6:302:a::29) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3700.1; Tue, 15 Dec 2020 19:06:21 +0000 Received: from MWHPR21MB0160.namprd21.prod.outlook.com ([fe80::2c14:392f:2f40:cd07]) by MWHPR21MB0160.namprd21.prod.outlook.com ([fe80::2c14:392f:2f40:cd07%6]) with mapi id 15.20.3700.011; Tue, 15 Dec 2020 19:06:21 +0000 From: "Bret Barkelew" To: "Kinney, Michael D" , "rfc@edk2.groups.io" , "leif@nuviainc.com" CC: "devel@edk2.groups.io" , "gaoliming@byosoft.com.cn" , "Andrew Fish (afish@apple.com)" , "Laszlo Ersek (lersek@redhat.com)" , Sean Brogan Subject: Re: [edk2-rfc] [RFC] Create supported branch from edk2-stable* tag (Required to address critical bug BZ3111) Thread-Topic: [edk2-rfc] [RFC] Create supported branch from edk2-stable* tag (Required to address critical bug BZ3111) Thread-Index: AQHW0xQei2ygqLEvv0moLTG/2ScQqqn4hCSZ Date: Tue, 15 Dec 2020 19:06:21 +0000 Message-ID: References: <20201215171648.GZ1664@vanye>, In-Reply-To: Accept-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: msip_labels: MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Enabled=True;MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SiteId=72f988bf-86f1-41af-91ab-2d7cd011db47;MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SetDate=2020-12-15T19:04:44.5447443Z;MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_ContentBits=0;MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Method=Privileged authentication-results: intel.com; dkim=none (message not signed) header.d=none;intel.com; dmarc=none action=none header.from=microsoft.com; x-originating-ip: [71.212.128.71] x-ms-publictraffictype: Email x-ms-office365-filtering-ht: Tenant x-ms-office365-filtering-correlation-id: 18500e93-8960-4fa2-ad07-08d8a12c8268 x-ms-traffictypediagnostic: MW2PR2101MB1100: x-ms-exchange-transport-forked: True x-ld-processed: 72f988bf-86f1-41af-91ab-2d7cd011db47,ExtAddr x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: zH2sahTQa52qWYJ6D8mh5HqqlvANLEwCN12MKBSS06TPslRofikfnYWjPyWcLXyIPQBqMA/eLHZiTZ3fSxah4nqFCJdh8pIWmjrnH1tcj8Z5IaoDXlNY7JGe+xe+B/1HHRYgyIrZ16dG3ZpeQpb8sBpC6HEJnQcyAd3MV8ABnJW3IswKEomEjUtRbaECqD/Qnks03e4dtBq3ca/02n5X+Spk+91qgYUnEmLwZazme1zyGj6RBKFhpyhRJeAqbdBPYr3d6abjTKuISmPY94jnONXce4b5RTq3vq/G3SUof3t07arTJ6lCU/YUgt6gLn/2nlUixWdwAiVSxKCbnsET8PUJKgBZgvaOLk5VD9X4xCLQeaJ1uSNe7EN2Y+7m4jmJxrqhFKmpAafCpGMW2ioLXaLi+qMete1Qcob6kk04tb5ewFN8/IXnyRzhCIGAvSd4Gx3LvJV6nZa+OCglxoTnjA== x-forefront-antispam-report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:MWHPR21MB0160.namprd21.prod.outlook.com;PTR:;CAT:NONE;SFS:(4636009)(346002)(366004)(136003)(376002)(52536014)(66556008)(66446008)(76116006)(26005)(64756008)(8936002)(6506007)(53546011)(9686003)(8990500004)(55016002)(107886003)(166002)(33656002)(5660300002)(110136005)(66476007)(71200400001)(186003)(8676002)(83380400001)(66946007)(4326008)(7696005)(508600001)(82950400001)(2906002)(966005)(54906003)(86362001)(82960400001)(10290500003);DIR:OUT;SFP:1102; x-ms-exchange-antispam-messagedata: =?us-ascii?Q?YNVpHSqf4P1Y2NIXJCXISZatJwu72Qq70FweZezGgLUK303pGJmqAU6EPD4I?= =?us-ascii?Q?Iz04PWDfOjFss5GyqXTurf3MYWklyJ0uGFDfll/wfcB0fEKU+y+WPnyvBI1L?= =?us-ascii?Q?B7zA60U3MLQHPr9BL4gZk40uYbbaHHJy51VPArKIfmyrelL7MJhpBxYTTqvi?= =?us-ascii?Q?rn66C64Ye4KPEI0xQ1e0JI9lW7rddKybEKhdtq+ovBmV63XtF7WmBDK9CSbU?= =?us-ascii?Q?mRrE8o1w3E2mrHbZLqaOho1+/To3JqWeL1xK489AQAEdXGlbuITN4kvIQPQo?= =?us-ascii?Q?LIt6Ee6YcqDJ5PhP8fDutSj0hVQyKNANPWlUJi61mTWlDNdR+rD1Ibp8aKv3?= =?us-ascii?Q?bgkUReTuESv7/zuvWz2yco5K62UOXWiICZhUZ1kG2g9FgwTvjhIcmrJAsnvN?= =?us-ascii?Q?UzRKsryeD3re3tmiCvwrxwnFWrClZhpK6DHpj38AS7Yho5V7C1c3kLEPdneo?= =?us-ascii?Q?viNw8ibZXKj6lDZGmxC2XvYYzUj0mx2YK2THzboo6HY/1VHcxJJDDkpvFJl/?= =?us-ascii?Q?5hfJEP+eibU1sXC33f+qGNIVahfaY9qqDwxTaXMqb7Ri5q4S/Qyw5lMQCnhz?= =?us-ascii?Q?cwM3LIizWT63GYkIDKxQbiufoWqimbum31PCvotny3bsDre9YKqBwUueAjgF?= =?us-ascii?Q?zrbLLqT9xD/HviDckq+bUSKLwNpooa3WDPj/r3oHXfl2NuCoLgrbnb6VLVHn?= =?us-ascii?Q?QmyAdzTMWwS1EmaoBX31kUiNdkHC0bMWBUYyAoZeFEo03uUN1/Q9d4KRnB1O?= =?us-ascii?Q?8xzBYuuq7897Zwto+fBpYDuaJVAzChlPdjY22niEj4Y/PH+epKif5nQ/86TA?= =?us-ascii?Q?w67jw3SNC8UxGmbVvv1cctyUAo0CEqHJbEMQbVT81a+bfOBRDGSQvsuKRQhy?= =?us-ascii?Q?HvgwrLCkLvcS9a1qml90OtUKXc875fQFkaV0KY5rmXLDjEkkhMHU373LhLiz?= =?us-ascii?Q?NyWIOvIVPSqfk9qB6qivh0FOjx6thU9cE2Vd+EaM9nmFqOhlx4ocgnygE6VG?= =?us-ascii?Q?JCK1c5s/ckEvjW6mOy6GdphHGw=3D=3D?= MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: MWHPR21MB0160.namprd21.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 18500e93-8960-4fa2-ad07-08d8a12c8268 X-MS-Exchange-CrossTenant-originalarrivaltime: 15 Dec 2020 19:06:21.0306 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: 8GJhcHz81DO5aAs303UcGjDLFgxQZXco1s+b71v5F2fqArl7ihiQIqDZ9NtMGmY8qnFypbWDk06qfVBJ0rSQqw== X-MS-Exchange-Transport-CrossTenantHeadersStamped: MW2PR2101MB1100 Content-Language: en-US Content-Type: multipart/alternative; boundary="_000_MWHPR21MB0160F6A58359D82C95599BAFEFC69MWHPR21MB0160namp_" --_000_MWHPR21MB0160F6A58359D82C95599BAFEFC69MWHPR21MB0160namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable FWIW, we tried both branches and tags in Mu, and have gotten more mileage o= ut of branches. We will still do tags periodically (to establish a point at= which all the sub repos were put through a full validation run), but our p= latform consumers have shown a preference for just living on the stabilized= branch. - Bret From: Kinney, Michael D Sent: Tuesday, December 15, 2020 10:57 AM To: rfc@edk2.groups.io; leif@nuviainc.com; Kinney, Michael D Cc: devel@edk2.groups.io; gaoliming@byosoft.c= om.cn; Andrew Fish (afish@apple.com); Laszlo Ersek (lersek@redhat.com); Sean Brogan; Bre= t Barkelew Subject: [EXTERNAL] RE: [edk2-rfc] [RFC] Create supported branch from edk2= -stable* tag (Required to address critical bug BZ3111) Hi Leif, I think you are suggesting that a local branch could be created from edk2-= stable202011 and the 2 commits cherry-picked onto that local branch and then create a tag on th= at local branch and only push the new tag to edk2 repo (e.g. edk2-stable202011.01). Correct? I think with this approach, we would wait for the community to request a n= ew stable dot tag (e.g. edk2-stable202011.01) with a specific set of commits. Another advantage of branch vs tag is that platforms that want to always u= se an edk2-stable* tag with all the known critical bug fixes can pull the branch to get the l= atest fixes. Or select a tag on the branch or a specific sha on the branch based on their platfor= m requirements. If a platform has to wait for a new stable dot tag then the platform can not = test with those critical fixes directly from the edk2 repo. They would have to create their own do= wnstream. I think between the CI use case and this downstream platform use case, a b= ranch has more advantages than a tag. I am fine with removing the redundant use of 'stable' and 'edk2' in the br= anch naming proposal. Proposal: stable/* Example: stable/202011 Thanks, Mike > -----Original Message----- > From: rfc@edk2.groups.io On Behalf Of Leif Lindholm > Sent: Tuesday, December 15, 2020 9:17 AM > To: Kinney, Michael D > Cc: devel@edk2.groups.io; rfc@edk2.groups.io; gaoliming@byosoft.com.cn; = Andrew Fish (afish@apple.com) ; > Laszlo Ersek (lersek@redhat.com) = ; 'Sean Brogan' ; 'Bret > Barkelew' > Subject: Re: [edk2-rfc] [RFC] Create supported branch from edk2-stable* = tag (Required to address critical bug BZ3111) > > Hi Mike, > > This looks fine to me. > I will add a potential tweak that I won't strongly advocate for, but > think should be considered: > We don't technically need a branch for this; a tag could be pushed > directly. > > On Tue, Dec 15, 2020 at 16:53:09 +0000, Kinney, Michael D wrote: > > Hello, > > > > The following bug has been fixed on edk2/master > > > > https://nam06.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%= 2Fbugzilla.tianocore.org%2Fshow_bug.cgi%3Fid%3D3111&data=3D04%7C01%7CBr= et.Barkelew%40microsoft.com%7C36133f4be9b24fbec5ca08d8a12b4024%7C72f988bf86= f141af91ab2d7cd011db47%7C1%7C0%7C637436554422046735%7CUnknown%7CTWFpbGZsb3d= 8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&= amp;sdata=3DEZCqLKBAXKgq8J40GFynYtqYIyhUpU7MIlT7wT4Cs9w%3D&reserved=3D0 > > https://nam06.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%= 2Fgithub.com%2Ftianocore%2Fedk2%2Fpull%2F1226&data=3D04%7C01%7CBret.Bar= kelew%40microsoft.com%7C36133f4be9b24fbec5ca08d8a12b4024%7C72f988bf86f141af= 91ab2d7cd011db47%7C1%7C0%7C637436554422056729%7CUnknown%7CTWFpbGZsb3d8eyJWI= joiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sd= ata=3DpQG7sjlHRxwh5mugH3vNKoZt88b%2BD7W4YHspsdb%2BQZ8%3D&reserved=3D0 > > > > This bug is also considered a critical bug against edk2-stable202011. = The behavior > > of the Variable Lock Protocol was changed in a non-backwards compatibl= e manner in > > edk2-stable202011 and this is impacting some downstream platforms. Th= e following > > 2 commits on edk2/master restore the original behavior of the Variable= Lock Protocol. > > > > https://nam06.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%= 2Fgithub.com%2Ftianocore%2Fedk2%2Fpull%2F1226%2Fcommits%2F893cfe2847b83da74= f53858d6acaa15a348bad7c&data=3D04%7C01%7CBret.Barkelew%40microsoft.com%= 7C36133f4be9b24fbec5ca08d8a12b4024%7C72f988bf86f141af91ab2d7cd011db47%7C1%7= C0%7C637436554422056729%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjo= iV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=3DRiNVhyT3fmoVRtLP= 0fJqbuP1Ow26tDM31J1O6%2B01wMs%3D&reserved=3D0 > > https://nam06.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%= 2Fgithub.com%2Ftianocore%2Fedk2%2Fpull%2F1226%2Fcommits%2F16491ba6a6e9a91ce= deeed45bc0fbdfde49f7968&data=3D04%7C01%7CBret.Barkelew%40microsoft.com%= 7C36133f4be9b24fbec5ca08d8a12b4024%7C72f988bf86f141af91ab2d7cd011db47%7C1%7= C0%7C637436554422056729%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjo= iV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=3DDpZO7U2yoqD%2BK%= 2F6OxIZoI%2FbIDMbtRr7UBMCBl9PxGkQ%3D&reserved=3D0 > > > > The request here is to create a supported branch from edk2-stable20201= 1 tag and apply > > these 2 commits as critical bug fixes on the supported branch. > > > > Since we started using the edk2-stable* tag process, there has not bee= n a request to create > > a supported branch from one of those tags. As a result, there are a c= ouple opens that > > need to be addressed: > > > > 1) Supported branch naming convention. > > > > Proposal: stable/edk2-stable* > > Example: stable/edk2-stable202011 > > For the bikeshedding part, if we're doing the branches, I support > using the stable/ prefix, but I also think this obviates the need to > include the word stable in the portion after /. > Since branches unlike tags don't have global namespace, I also think > there is no need for the edk2 portion of the name. > So an example branch name could be: > stable/202011 > > > 2) CI requirements for supported branches. > > > > Proposal: Update .azurepipelines yml files to also trigger on stab= le/* branches > > and update GitHub settings so stable/* branches are protected bran= ches. > > This would of course mandate the use of branches. > > > 3) Release requirements for supported branches. > > > > Proposal: If there are a significant number of critical fixes appli= ed to > > a stable/edk2-stable* branch, then a request for a release can be m= ade that > > would trigger focused testing of the supported branch and creation = of a new > > release. If all testing passes, then a tag is created on the stabl= e/edk2-stable* > > branch and a release is created on GitHub that summarizes the set o= f critical > > fixes and the testing performed. > > > > Proposal: edk2-stable. > > Example : edk2-stable201111.01 > > Sounds good to me. > > Best Regards, > > Leif > > > Please let me know if you have any feedback or comments on this propos= al. The goal > > is to close on this topic this week. > > > > Thank you, > > > > Mike > > >=20 > --_000_MWHPR21MB0160F6A58359D82C95599BAFEFC69MWHPR21MB0160namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

FWIW, we tried both branches and tags in Mu, and ha= ve gotten more mileage out of branches. We will still do tags periodically = (to establish a point at which all the sub repos were put through a full va= lidation run), but our platform consumers have shown a preference for just living on the stabilized branch.

 

- Bret

 

From: Kinney, Michael D
Sent: Tuesday, December 15, 2020 10:57 AM
To: rfc@edk2.groups.io; <= a href=3D"mailto:leif@nuviainc.com"> leif@nuviainc.com; Kinne= y, Michael D
Cc: devel@edk2.groups.io; gaoliming@byosoft.com.cn; Andrew Fi= sh (afish@apple.com); Laszlo Ersek <lersek@redhat.com>= ; (lersek@redhat.com); Sean Brogan; Bret Barkelew
Subject: [EXTERNAL] RE: [edk2-rfc] [RFC] Create supported branch fr= om edk2-stable* tag (Required to address critical bug BZ3111)

 

Hi Leif,

I think you are suggesting that a local branch could be created from edk2-= stable202011 and the
2 commits cherry-picked onto that local branch and then create a tag on th= at local branch and
only push the new tag to edk2 repo (e.g. edk2-stable202011.01).  Corr= ect?

I think with this approach, we would wait for the community to request a n= ew stable dot tag
(e.g. edk2-stable202011.01) with a specific set of commits.

Another advantage of branch vs tag is that platforms that want to always u= se an edk2-stable*
tag with all the known critical bug fixes can pull the branch to get the l= atest fixes.  Or select
a tag on the branch or a specific sha on the branch based on their platfor= m requirements.  If
a platform has to wait for a new stable dot tag then the platform can not = test with those critical
fixes directly from the edk2 repo.  They would have to create their o= wn downstream.

I think between the CI use case and this downstream platform use case, a b= ranch has more
advantages than a tag.

I am fine with removing the redundant use of 'stable' and 'edk2' in the br= anch naming proposal.

    Proposal: stable/*
    Example:  stable/202011

Thanks,

Mike

> -----Original Message-----
> From: rfc@edk2.groups.io <rfc@edk2.groups.io> On Behalf Of Leif= Lindholm
> Sent: Tuesday, December 15, 2020 9:17 AM
> To: Kinney, Michael D <michael.d.kinney@intel.com>
> Cc: devel@edk2.groups.io; rfc@edk2.groups.io; gaoliming@byosoft.com.c= n; Andrew Fish (afish@apple.com) <afish@apple.com>;
> Laszlo Ersek <lersek@redhat.com> (lersek@redhat.com) <lersek= @redhat.com>; 'Sean Brogan' <sean.brogan@microsoft.com>; 'Bret
> Barkelew' <Bret.Barkelew@microsoft.com>
> Subject: Re: [edk2-rfc] [RFC] Create supported branch from edk2-stabl= e* tag (Required to address critical bug BZ3111)
>
> Hi Mike,
>
> This looks fine to me.
> I will add a potential tweak that I won't strongly advocate for, but<= br> > think should be considered:
> We don't technically need a branch for this; a tag could be pushed > directly.
>
> On Tue, Dec 15, 2020 at 16:53:09 +0000, Kinney, Michael D wrote:
> > Hello,
> >
> > The following bug has been fixed on edk2/master
> >
> >     https://nam06.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fbugzil= la.tianocore.org%2Fshow_bug.cgi%3Fid%3D3111&amp;data=3D04%7C01%7CBret.B= arkelew%40microsoft.com%7C36133f4be9b24fbec5ca08d8a12b4024%7C72f988bf86f141= af91ab2d7cd011db47%7C1%7C0%7C637436554422046735%7CUnknown%7CTWFpbGZsb3d8eyJ= WIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&= amp;sdata=3DEZCqLKBAXKgq8J40GFynYtqYIyhUpU7MIlT7wT4Cs9w%3D&amp;reserved= = =3D0
> >     https://nam06.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fgithub= .com%2Ftianocore%2Fedk2%2Fpull%2F1226&amp;data=3D04%7C01%7CBret.Barkele= w%40microsoft.com%7C36133f4be9b24fbec5ca08d8a12b4024%7C72f988bf86f141af91ab= 2d7cd011db47%7C1%7C0%7C637436554422056729%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiM= C4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sd= ata=3DpQG7sjlHRxwh5mugH3vNKoZt88b%2BD7W4YHspsdb%2BQZ8%3D&amp;reserved= =3D0
> >
> > This bug is also considered a critical bug against edk2-stable20= 2011.  The behavior
> > of the Variable Lock Protocol was changed in a non-backwards com= patible manner in
> > edk2-stable202011 and this is impacting some downstream platform= s.  The following
> > 2 commits on edk2/master restore the original behavior of the Va= riable Lock Protocol.
> >
> >     https://nam06.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fgithub= .com%2Ftianocore%2Fedk2%2Fpull%2F1226%2Fcommits%2F893cfe2847b83da74f53858d6= acaa15a348bad7c&amp;data=3D04%7C01%7CBret.Barkelew%40microsoft.com%7C36= 133f4be9b24fbec5ca08d8a12b4024%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7= C637436554422056729%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2l= uMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=3DRiNVhyT3fmoVRtLP= 0fJqbuP1Ow26tDM31J1O6%2B01wMs%3D&amp;reserved=3D0
> >     https://nam06.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fgithub= .com%2Ftianocore%2Fedk2%2Fpull%2F1226%2Fcommits%2F16491ba6a6e9a91cedeeed45b= c0fbdfde49f7968&amp;data=3D04%7C01%7CBret.Barkelew%40microsoft.com%7C36= 133f4be9b24fbec5ca08d8a12b4024%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7= C637436554422056729%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2l= uMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=3DDpZO7U2yoqD%2BK%= 2F6OxIZoI%2FbIDMbtRr7UBMCBl9PxGkQ%3D&amp;reserved=3D0
> >
> > The request here is to create a supported branch from edk2-stabl= e202011 tag and apply
> > these 2 commits as critical bug fixes on the supported branch. > >
> > Since we started using the edk2-stable* tag process, there has n= ot been a request to create
> > a supported branch from one of those tags.  As a result, th= ere are a couple opens that
> > need to be addressed:
> >
> > 1) Supported branch naming convention.
> >
> >     Proposal: stable/edk2-stable*
> >     Example:  stable/edk2-stable202011<= br> >
> For the bikeshedding part, if we're doing the branches, I support
> using the stable/ prefix, but I also think this obviates the need to<= br> > include the word stable in the portion after /.
> Since branches unlike tags don't have global namespace, I also think<= br> > there is no need for the edk2 portion of the name.
> So an example branch name could be:
>   stable/202011
>
> > 2) CI requirements for supported branches.
> >
> >     Proposal: Update .azurepipelines yml fil= es to also trigger on stable/* branches
> >     and update GitHub settings so stable/* b= ranches are protected branches.
>
> This would of course mandate the use of branches.
>
> > 3) Release requirements for supported branches.
> >
> >    Proposal: If there are a significant number of= critical fixes applied to
> >    a stable/edk2-stable* branch, then a request f= or a release can be made that
> >    would trigger focused testing of the supported= branch and creation of a new
> >    release.  If all testing passes, then a t= ag is created on the stable/edk2-stable*
> >    branch and a release is created on GitHub that= summarizes the set of critical
> >    fixes and the testing performed.
> >
> >    Proposal: edk2-stable<YYYY><MM>.&l= t;XX>
> >    Example : edk2-stable201111.01
>
> Sounds good to me.
>
> Best Regards,
>
> Leif
>
> > Please let me know if you have any feedback or comments on this = proposal.  The goal
> > is to close on this topic this week.
> >
> > Thank you,
> >
> > Mike
>
>
>
>

 

--_000_MWHPR21MB0160F6A58359D82C95599BAFEFC69MWHPR21MB0160namp_--