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.95]) by mx.groups.io with SMTP id smtpd.web08.1214.1608230791706445971 for ; Thu, 17 Dec 2020 10:46:32 -0800 Authentication-Results: mx.groups.io; dkim=pass header.i=@microsoft.com header.s=selector2 header.b=fmz+Aii5; spf=pass (domain: microsoft.com, ip: 40.107.223.95, mailfrom: bret.barkelew@microsoft.com) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=gg5zzqZB6HFFRhAnBq+pmNLan4lV+gkA/yS3z9yNBiQarFg/gcinep+mKI1FVUWCVOjSAyKQ1BTlXh3s+DqlkpRbKk9aVKoJJ/O5smqTy5Wm+yxqsydkwxbs6l0XqAuGviHXcrh1M3CwuGxjj/HHDhcCBPe8TVuGneNRAHmHQY7gWYts1Y77p9uJcXymtGw2LLmrP32bPqwEZumSDWeczX3z3LUK4WehujwnvAmV93+Dc4EyjpftGaoSzVCIMZbgRk59D8DGZdplUdHoB57ibyHAcIYK5eEeXB9kqhfnRbrCV12EAYTZ6TJ7UV2pAiijsiONGzuADBEYQ6KoBwSSnQ== 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=+4ev079NvXM7alEVIpP+XCa/D5X8mzznDLoBWgeA334=; b=fjeFQEb7yt3NKTldA5GBObhFivUZUVy/GCXbJVtvgoYoLZC3VpmQTOE8w4vEY8v4I7XIlTrco80+xQziyaXlu5jK5OmtQV+q1Uv0cdNdRNEQYO/yjmoGxuURgXuBebpzMJ41CqW4PSm7SgbwDRf+7PxjdvSEhaDqIsK1Njb3Lb3QT7onLpe0+oZ7WZ9paeBuSxcIWFrFUFyjH4oXQi+Nhf60Wr5shKXt3rXALTH86bCS1pQBBf9Io1dFug40MT9SmIBEpUmKx78lSo/thO9/X5UhPED+s4LbJFqc5Tx/69DBUjxMc2zFMWGyyG1/MtfBt9MGjlZmLTNs8HUiC/nDng== 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=+4ev079NvXM7alEVIpP+XCa/D5X8mzznDLoBWgeA334=; b=fmz+Aii5RbNxffiJ3GYfXgeCw7dyJsGpTGQXiK56POnimso20jf1xEubb0W5TFvnTLMefbMXb+TIxFbJyTq1lObJanjBDv2y+ky9xGNRfcwngeVFek9PP/1P20LViCj3ZEm+5Y8RQWvzqJzSMpa3HdmDyEcG4L41nMoi+ZK+gQc= Received: from (2603:10b6:300:78::18) by MW2PR2101MB0908.namprd21.prod.outlook.com (2603:10b6:302:10::28) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3700.4; Thu, 17 Dec 2020 18:46:30 +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.019; Thu, 17 Dec 2020 18:46:30 +0000 From: "Bret Barkelew" To: Laszlo Ersek , "Kinney, Michael D" , "devel@edk2.groups.io" , "rfc@edk2.groups.io" , "gaoliming@byosoft.com.cn" , "Andrew Fish (afish@apple.com)" , Leif Lindholm , Sean Brogan Subject: Re: [EXTERNAL] Re: [RFC V2] Create supported branch from edk2-stable* tag (Required to address critical bug BZ3111) Thread-Topic: [EXTERNAL] Re: [RFC V2] Create supported branch from edk2-stable* tag (Required to address critical bug BZ3111) Thread-Index: AdbTQdbugDu5ioVaSS6HQexwJ4FxCQBOZiGAAApTwHY= Date: Thu, 17 Dec 2020 18:46:29 +0000 Message-ID: References: , 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-17T18:45:08.5541749Z;MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_ContentBits=0;MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Method=Privileged authentication-results: redhat.com; dkim=none (message not signed) header.d=none;redhat.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: 409d1552-d0b0-494e-9262-08d8a2bc114f x-ms-traffictypediagnostic: MW2PR2101MB0908: 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:9508; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: pUpayNLO79Dem0lSzttjWf6iHlwJJgSDg+guP/w4S4IyKfZ7epeoJ5g6ZwbGGKFvwnTT1xcF/yKEzkzea4/8kbaC3q1rK1umDFATR3nSW7Aqb7xNqgnage+8gxkfgmtL4uW3pI+egY/UujROfo6PJGh5Yfm2M8cvKDkgdnNYfcNYEv87HN/Xt9v368SpgobKBaOJluYSI7EP+g8m3Yc+SCNQ7OiSG9yH0eVnjQQDzYqDRZN34r3sn/XFO+xgmzbh/y0Zf429nJBOehjaYQbML0jfkYjE+xpM0bXDBOyj++YwMcB1YIoJRDmp/fE3kNiAjlYQU82w0kSQXCxZdHtYVYYi6uJfa8U6TFyLJbBc0vD8lf2NoHVc+ZvwYb1B5CXkPpgBR0JOW251WsWPIN4/8rtR0VD8TMCtG+fEoqGgErNnARtkO+enHcIu3fiiEgIDjBey5nUOkCVjC+eYussPOg== 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)(366004)(39860400002)(376002)(346002)(136003)(396003)(55016002)(316002)(66446008)(8936002)(2906002)(10290500003)(66946007)(9686003)(82950400001)(110136005)(6636002)(66556008)(64756008)(186003)(53546011)(5660300002)(66476007)(82960400001)(6506007)(52536014)(966005)(83380400001)(166002)(7696005)(76116006)(478600001)(86362001)(8990500004)(26005)(8676002)(33656002)(71200400001);DIR:OUT;SFP:1102; x-ms-exchange-antispam-messagedata: =?Windows-1252?Q?OZwePlywaGPjsBvLU1ntekF4LOfQoGwrG9FjITBo68aveQjr2A/BnlA1?= =?Windows-1252?Q?DIoQ3H/kCTkhp5KkzF3v5vMTaWe+sl4sjl3pPxHiPa39JkSVscw3/GSv?= =?Windows-1252?Q?sy/PIaZCDFXkO+omuBw4hF6B7tD7g0le6uu3ZLPaeXrWYm2nRLC+EyGv?= =?Windows-1252?Q?xrbk/bVXf96S0ula2ZaAmWx+sqbiaq6G2JDgNr5mYwDCBOIm4dEZErO5?= =?Windows-1252?Q?f1/7KElBHZiyL0Afg4UkEoeGddv5hq9a6BNLXHS3pMLPVHXhhnIUOz7H?= =?Windows-1252?Q?PuqW1T/axJkvFXOjhKhnnIs1KCtXgGfmeGTdiFzo5gGnHHlrJgVKS+8L?= =?Windows-1252?Q?IE4Qkf+OZsmEyhKRjVb9crP31KvwGtFt/Y1XDCkEoT+ubx62jMCXNm6o?= =?Windows-1252?Q?TtPAx+nUtmzRL8K69/ackAn9rxtOywWg17iLHuwmXua/6lG7oBRPwtbX?= =?Windows-1252?Q?CAtEbXBosWDoopTaXbeTsq0+dwobY9Y+5fB5VyJMtqRVi2SlEovEvvGZ?= =?Windows-1252?Q?O+n2WYMRSsY0yghdnGoJdL0S9KYUJYb4NYVX8iN5RcsSqSILMKT2kdGW?= =?Windows-1252?Q?Ees3Xrs328gfxLzw3glLEuj1pDVlY9mgMkx5UyH0o1vsZaAvFJkXWx6c?= =?Windows-1252?Q?N0diCC1XgTpiQ1tmqCwmWGYWPL0lpzGR1WPGCwX+zyQbrST6W17jIcpr?= =?Windows-1252?Q?Omdod6u3LSR9IZidywjnzjedgOFRBi6I89yCCkWCMT3oBXs+mKCXcXTB?= =?Windows-1252?Q?rsiqRugEVWrwOOpKyeiJz9rU2kwSRT1u0EEBP070gDMkoo/GRE6G9PxD?= =?Windows-1252?Q?u4iocOO1nu9nwkFjj0xGkfKp4GTeK4/xj18vVP/oWxqHIH+2kMF+jWEk?= =?Windows-1252?Q?lpSAsOkcjevVJabi/+ar7ylzwnQvQ8K2KeZRwB5xfoBaNBPqi9uT/1oR?= =?Windows-1252?Q?gZPqqJd1VTaT2ryeUYEDmrR+CcspU2+EBpdduxEe5jwhWyar0prHwMqj?= =?Windows-1252?Q?/9WrbVSKLTl++mdLSUL++9sE2cDD+x3L+If6KgYKQNLU2ZJmYi882HYN?= =?Windows-1252?Q?YpvScOlBzx4WLAfN?= 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: 409d1552-d0b0-494e-9262-08d8a2bc114f X-MS-Exchange-CrossTenant-originalarrivaltime: 17 Dec 2020 18:46:29.9994 (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: I08xf7A4Tkve//VP15qVC7fjB+elfBWvXFu8a1M7EzSyG1VLf0fn5KCg7UPvDesmm1mp9eLBaqnKkywrjGUG3A== X-MS-Exchange-Transport-CrossTenantHeadersStamped: MW2PR2101MB0908 Content-Language: en-US Content-Type: multipart/alternative; boundary="_000_MWHPR21MB01605323C4302D6D07AB85A4EFC49MWHPR21MB0160namp_" --_000_MWHPR21MB01605323C4302D6D07AB85A4EFC49MWHPR21MB0160namp_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable =93I agree with Liming that stable branches should have a predefined lifetime. Keeping stable branches regression-free is very difficult and ungrateful work, and the community should not have expectations that we're going to do "LTS" branches.=94 Seconded. We actually had to update our release process with this blurb rec= ently: https://microsoft.github.io/mu/How/release_process/#post-lts-and-archiving - Bret From: Laszlo Ersek Sent: Thursday, December 17, 2020 5:50 AM To: Kinney, Michael D; devel@edk2.groups= .io; rfc@edk2.groups.io; gaoliming@byosoft.com.cn; Andrew Fis= h (afish@apple.com); Leif Lindholm; Sean Brogan; Bret Barkelew Subject: [EXTERNAL] Re: [RFC V2] Create supported branch from edk2-stable* = tag (Required to address critical bug BZ3111) On 12/16/20 01:24, Kinney, Michael D wrote: > Hello, > > The following bug has been fixed on edk2/master > > https://nam06.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fb= ugzilla.tianocore.org%2Fshow_bug.cgi%3Fid%3D3111&data=3D04%7C01%7Cbret.= barkelew%40microsoft.com%7C092cd97468a645f68e4308d8a292a636%7C72f988bf86f14= 1af91ab2d7cd011db47%7C1%7C0%7C637438098026646126%7CUnknown%7CTWFpbGZsb3d8ey= JWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&= ;sdata=3DwE%2B9eA3XrRxS58KUk6DbFZmvX9nvmWopzGoVRN5713k%3D&reserved=3D0 > https://nam06.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fg= ithub.com%2Ftianocore%2Fedk2%2Fpull%2F1226&data=3D04%7C01%7Cbret.barkel= ew%40microsoft.com%7C092cd97468a645f68e4308d8a292a636%7C72f988bf86f141af91a= b2d7cd011db47%7C1%7C0%7C637438098026646126%7CUnknown%7CTWFpbGZsb3d8eyJWIjoi= MC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata= =3DMnXglF%2FvtUDAouXJvBUIRFq7TuPL2dKXohXwcEuY3zc%3D&reserved=3D0 > > This bug is also considered a critical bug against edk2-stable202011. Th= e behavior > of the Variable Lock Protocol was changed in a non-backwards compatible m= anner in > edk2-stable202011 and this is impacting some downstream platforms. The f= ollowing > 2 commits on edk2/master restore the original behavior of the Variable Lo= ck Protocol. > > https://nam06.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fg= ithub.com%2Ftianocore%2Fedk2%2Fpull%2F1226%2Fcommits%2F893cfe2847b83da74f53= 858d6acaa15a348bad7c&data=3D04%7C01%7Cbret.barkelew%40microsoft.com%7C0= 92cd97468a645f68e4308d8a292a636%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%= 7C637438098026646126%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2= luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=3Dh19eR7KFYlerrva%2FV= GMDb7DMVIUihINgAlOh96Hb2xI%3D&reserved=3D0 > https://nam06.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fg= ithub.com%2Ftianocore%2Fedk2%2Fpull%2F1226%2Fcommits%2F16491ba6a6e9a91cedee= ed45bc0fbdfde49f7968&data=3D04%7C01%7Cbret.barkelew%40microsoft.com%7C0= 92cd97468a645f68e4308d8a292a636%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%= 7C637438098026656126%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2= luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=3D8nCkmGD5jRyfrsMID0E= SAcUb8plWrRkFafvhPiS2Zo8%3D&reserved=3D0 > > The request here is to create a supported branch from edk2-stable202011 t= ag 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 been a= request to create > a supported branch from one of those tags. As a result, there are a coup= le opens that > need to be addressed: > > 1) Supported branch naming convention. > > Proposal: stable/ > Example: stable/202011 > > 2) CI requirements for supported branches. > > Proposal: Update .azurepipelines yml files to also trigger on stable/= * branches > and update GitHub settings so stable/* branches are protected branche= s. > > 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 for 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 tag is created on the stable/e= dk2-stable* > branch and a release is created on GitHub that summarizes the set of c= ritical > fixes and the testing performed. > > Proposal: edk2-stable. > Example : edk2-stable201111.01 > > Please let me know if you have any feedback or comments on this proposal.= The goal > is to close on this topic this week. - Looks good; just a typo in the example: "edk2-stable201111.01" should use 2020, not 2011. - I agree with Liming that stable branches should have a predefined lifetime. Keeping stable branches regression-free is very difficult and ungrateful work, and the community should not have expectations that we're going to do "LTS" branches. That's too resource hungry; companies have dedicated "maintenance engineer" positions for that. Here's an example stable process: https://nam06.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fgit.qem= u.org%2F%3Fp%3Dqemu.git%3Ba%3Dblob_plain%3Bf%3Ddocs%2Fdevel%2Fstable-proces= s.rst%3Bhb%3DHEAD&data=3D04%7C01%7Cbret.barkelew%40microsoft.com%7C092c= d97468a645f68e4308d8a292a636%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C6= 37438098026656126%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luM= zIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=3DbOmSbEHuU%2BqLr3mdmhP%= 2Foq%2BR7yy%2BVNUWbG367yhFwQE%3D&reserved=3D0 I would recommend that, initially, we only promise support for the last stable tag's branch. - Including a unit test (if it exists) with the actual bugfix on a stable branch seems important to me. Thanks Laszlo --_000_MWHPR21MB01605323C4302D6D07AB85A4EFC49MWHPR21MB0160namp_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable

=93I agree with Liming that stable branches should h= ave a predefined
lifetime. Keeping stable branches regression-free is very difficult and
ungrateful work, and the community should not have expectations that
we're going to do "LTS" branches.=94

 

Seconded. We actually had to update our release proc= ess with this blurb recently:

https://microsoft.github.io/mu/How/release_process/#= post-lts-and-archiving

 

- Bret

 

From: Laszlo Ersek
Sent: Thursday, December 17, 2020 5:50 AM
To: Kinney, Michael D<= /a>; devel@edk2.groups.io; rfc@edk2.gr= oups.io; gaoliming@byosoft.com.cn; <= a href=3D"mailto:afish@apple.com"> Andrew Fish (afish@apple.com); Lei= f Lindholm; Sean Brogan; Bret Barkelew
Subject: [EXTERNAL] Re: [RFC V2] Create supported branch from edk2-s= table* tag (Required to address critical bug BZ3111)

 

On 12/16/20 01:24, Ki= nney, Michael D wrote:
> Hello,
>
> The following bug has been fixed on edk2/master
>
>     https://nam06.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fbugzill= a.tianocore.org%2Fshow_bug.cgi%3Fid%3D3111&amp;data=3D04%7C01%7Cbret.ba= rkelew%40microsoft.com%7C092cd97468a645f68e4308d8a292a636%7C72f988bf86f141a= f91ab2d7cd011db47%7C1%7C0%7C637438098026646126%7CUnknown%7CTWFpbGZsb3d8eyJW= IjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&a= mp;sdata=3DwE%2B9eA3XrRxS58KUk6DbFZmvX9nvmWopzGoVRN5713k%3D&amp;reserve= d=3D0
>     https://nam06.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fgithub.= com%2Ftianocore%2Fedk2%2Fpull%2F1226&amp;data=3D04%7C01%7Cbret.barkelew= %40microsoft.com%7C092cd97468a645f68e4308d8a292a636%7C72f988bf86f141af91ab2= d7cd011db47%7C1%7C0%7C637438098026646126%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC= 4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sda= ta=3DMnXglF%2FvtUDAouXJvBUIRFq7TuPL2dKXohXwcEuY3zc%3D&amp;reserved=3D0<= /a>
>
> This bug is also considered a critical bug against edk2-stable202011.&= nbsp; 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.&nbs= p; The 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%2F893cfe2847b83da74f53858d6a= caa15a348bad7c&amp;data=3D04%7C01%7Cbret.barkelew%40microsoft.com%7C092= cd97468a645f68e4308d8a292a636%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C= 637438098026646126%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2lu= MzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=3Dh19eR7KFYlerrva%2= FVGMDb7DMVIUihINgAlOh96Hb2xI%3D&amp;reserved=3D0
>     https://nam06.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fgithub.= com%2Ftianocore%2Fedk2%2Fpull%2F1226%2Fcommits%2F16491ba6a6e9a91cedeeed45bc= 0fbdfde49f7968&amp;data=3D04%7C01%7Cbret.barkelew%40microsoft.com%7C092= cd97468a645f68e4308d8a292a636%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C= 637438098026656126%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2lu= MzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=3D8nCkmGD5jRyfrsMID= 0ESAcUb8plWrRkFafvhPiS2Zo8%3D&amp;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 ar= e a couple opens that
> need to be addressed:
>
> 1) Supported branch naming convention.
>
>     Proposal: stable/<YYYY><MM>
>     Example:  stable/202011
>
> 2) CI requirements for supported branches.
>
>     Proposal: Update .azurepipelines yml files to = also trigger on stable/* branches
>     and update GitHub settings so stable/* branche= s are protected branches.
>
> 3) Release requirements for supported branches.
>
>    Proposal: If there are a significant number of criti= cal fixes applied to
>    a stable/edk2-stable* branch, then a request for a r= elease can be made that
>    would trigger focused testing of the supported branc= h and creation of a new
>    release.  If all testing passes, then a tag is = created on the stable/edk2-stable*
>    branch and a release is created on GitHub that summa= rizes the set of critical
>    fixes and the testing performed.
>
>    Proposal: edk2-stable<YYYY><MM>.<XX&g= t;
>    Example : edk2-stable201111.01
>
> 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.

- Looks good; just a typo in the example: "edk2-stable201111.01" = should
use 2020, not 2011.


- I agree with Liming that stable branches should have a predefined
lifetime. Keeping stable branches regression-free is very difficult and
ungrateful work, and the community should not have expectations that
we're going to do "LTS" branches. That's too resource hungry; com= panies
have dedicated "maintenance engineer" positions for that.

Here's an example stable process:

h= ttps://nam06.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fgit.qemu= .org%2F%3Fp%3Dqemu.git%3Ba%3Dblob_plain%3Bf%3Ddocs%2Fdevel%2Fstable-process= .rst%3Bhb%3DHEAD&amp;data=3D04%7C01%7Cbret.barkelew%40microsoft.com%7C0= 92cd97468a645f68e4308d8a292a636%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%= 7C637438098026656126%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2= luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=3DbOmSbEHuU%2BqLr= 3mdmhP%2Foq%2BR7yy%2BVNUWbG367yhFwQE%3D&amp;reserved=3D0

I would recommend that, initially, we only promise support for the last
stable tag's branch.


- Including a unit test (if it exists) with the actual bugfix on a
stable branch seems important to me.

Thanks
Laszlo

 

--_000_MWHPR21MB01605323C4302D6D07AB85A4EFC49MWHPR21MB0160namp_--