From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail.byosoft.com.cn (mail.byosoft.com.cn [58.240.74.242]) by mx.groups.io with SMTP id smtpd.web12.2144.1608171213728959006 for ; Wed, 16 Dec 2020 18:13:35 -0800 Authentication-Results: mx.groups.io; dkim=missing; spf=none, err=permanent DNS error (domain: byosoft.com.cn, ip: 58.240.74.242, mailfrom: gaoliming@byosoft.com.cn) Received: from DESKTOPS6D0PVI ([58.246.60.130]) (envelope-sender ) by 192.168.6.13 with ESMTP for ; Thu, 17 Dec 2020 10:13:23 +0800 X-WM-Sender: gaoliming@byosoft.com.cn X-WM-AuthFlag: YES X-WM-AuthUser: gaoliming@byosoft.com.cn From: "gaoliming" To: "'Kinney, Michael D'" , , , "'Andrew Fish'" , "'Leif Lindholm'" , , "'Sean Brogan'" , "'Bret Barkelew'" References: <005201d6d349$6f72b4b0$4e581e10$@byosoft.com.cn> In-Reply-To: Subject: =?UTF-8?B?5Zue5aSNOiBbUkZDIFYyXSBDcmVhdGUgc3VwcG9ydGVkIGJyYW5jaCBmcm9tIGVkazItc3RhYmxlKiB0YWcgKFJlcXVpcmVkIHRvIGFkZHJlc3MgY3JpdGljYWwgYnVnIEJaMzExMSk=?= Date: Thu, 17 Dec 2020 10:13:26 +0800 Message-ID: <002801d6d41a$347d1860$9d774920$@byosoft.com.cn> MIME-Version: 1.0 X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQKH7p2ep/ntkJpdYGL/0IuxskQGzgC5bNZLAXRXJ/Coht1wAA== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Language: zh-cn Mike: > -----=E9=82=AE=E4=BB=B6=E5=8E=9F=E4=BB=B6----- > =E5=8F=91=E4=BB=B6=E4=BA=BA: Kinney, Michael D = > =E5=8F=91=E9=80=81=E6=97=B6=E9=97=B4: = 2020=E5=B9=B412=E6=9C=8816=E6=97=A5 10:52 > =E6=94=B6=E4=BB=B6=E4=BA=BA: gaoliming ; = devel@edk2.groups.io; > rfc@edk2.groups.io; 'Andrew Fish' ; 'Leif Lindholm' > ; lersek@redhat.com; 'Sean Brogan' > ; 'Bret Barkelew' > ; Kinney, Michael D > > =E4=B8=BB=E9=A2=98: RE: [RFC V2] Create supported branch from = edk2-stable* tag (Required > to address critical bug BZ3111) >=20 > > -----Original Message----- > > From: gaoliming > > Sent: Tuesday, December 15, 2020 5:19 PM > > To: Kinney, Michael D ; > devel@edk2.groups.io; rfc@edk2.groups.io; 'Andrew Fish' > > ; 'Leif Lindholm' ; > lersek@redhat.com; 'Sean Brogan' ; > > 'Bret Barkelew' > > Subject: =E5=9B=9E=E5=A4=8D: [RFC V2] Create supported branch from = edk2-stable* tag > (Required to address critical bug BZ3111) > > > > Mike: > > > > > -----=E9=82=AE=E4=BB=B6=E5=8E=9F=E4=BB=B6----- > > > =E5=8F=91=E4=BB=B6=E4=BA=BA: Kinney, Michael D = > > > =E5=8F=91=E9=80=81=E6=97=B6=E9=97=B4: = 2020=E5=B9=B412=E6=9C=8816=E6=97=A5 8:25 > > > =E6=94=B6=E4=BB=B6=E4=BA=BA: devel@edk2.groups.io; = rfc@edk2.groups.io; > > > gaoliming@byosoft.com.cn; Andrew Fish (afish@apple.com) > > > ; Leif Lindholm ; Laszlo Ersek > > > (lersek@redhat.com) ; 'Sean > > > Brogan' ; 'Bret Barkelew' > > > ; Kinney, Michael D > > > > > > =E4=B8=BB=E9=A2=98: [RFC V2] Create supported branch from = edk2-stable* tag (Required > to > > > address critical bug BZ3111) > > > > > > Hello, > > > > > > The following bug has been fixed on edk2/master > > > > > > https://bugzilla.tianocore.org/show_bug.cgi?id=3D3111 > > > https://github.com/tianocore/edk2/pull/1226 > > > > > > This bug is also considered a critical bug against = edk2-stable202011. The > > > behavior > > > of the Variable Lock Protocol was changed in a non-backwards = compatible > > > manner in > > > edk2-stable202011 and this is impacting some downstream platforms. > The > > > following > > > 2 commits on edk2/master restore the original behavior of the = Variable > Lock > > > Protocol. > > > > > > > > > > https://github.com/tianocore/edk2/pull/1226/commits/893cfe2847b83da74f > > > 53858d6acaa15a348bad7c > > > > > > > https://github.com/tianocore/edk2/pull/1226/commits/16491ba6a6e9a91ce > > > deeed45bc0fbdfde49f7968 > > > > > [Liming] This one is for unit test. It is not critical fix. I don't = think it is > required. >=20 >=20 > I agree it is not strictly required for functionality, but the bug fix = that is > required > was reviewed and submitted in a PR as a patch series. I think = critical bug > fixes should > be applied to a supported branch at the same granularity they were > submitted to the > trunk. Since the EDK II CI system does not evaluate the stability of = each > patch in > a patch series, there is a risk to take portions of a patch series. >=20 > I suggest when a critical bug fix is identified, that we start with = cherry-picking > all the patches in the patch series. If there is a specific concern = about taking > the entire patch series, then that can be discussed and potentially a = different > patch series can be applied to the supported branch. This would = require CI > on > supported branch to make sure the quality and functionality are the = same. >=20 This case is clear. One commit is for the bug fix, another is for the = unit test.=20 If the unit test is also important for this fix, it can be cherry-pick. = I understand the critical bug fix is for the functionality only. > > > > > The request here is to create a supported branch from = edk2-stable202011 > 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 = been a > > > request to create > > > a supported branch from one of those tags. As a result, there are = a > couple > > > opens that > > > need to be addressed: > > > > > > 1) Supported branch naming convention. > > > > > > Proposal: stable/ > > > Example: stable/202011 > > Here is my suggestion on the live period of the stable tag branch. > > The stable tag branch will be created only when the critical issue = is found in > this stable tag. By default, no stable tag > > branch is created. > > Now, the quarterly stable tag will be created every three months. = So, this > branch will exist for at most three months. > > Once next stable tag is created, new stable tag will be used. = Previous stable > tag branch will not be maintained. > > That means only latest stable tag branch will be maintained if it is = created. >=20 > It is hard to predict how downstream platforms use a stable tag or a > supported branch. > If a downstream consumer identifies a critical bug in a previous = stable tag or > a supported branch, then that bug report needs to be evaluated and > determine if > the bug fix needs to be applied to a stable branch or not. I do not = think we > should > reject all requests just because there is a more recent stable tag. = We need > to evaluate each request. >=20 If stable branch requires long term maintain, the stable branches will = become more and more, the branch maintain effort will be more and more. It may not be workable = in open source edk2 community unless there is the dedicated branch maintainers. So, I suggest that downstream consumers maintain their downstream branch = to include the hot fix.=20 Edk2 stable branch is the reference for the downstream users. Thanks Liming > We do want to encourage all platforms under development to use the = latest > stable > tag. But once a platform is released as a product using a specific = stable tag > they may prefer to continue to use that stable tag for long term = maintenance > of that platform. >=20 > > > > > > > > 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 > > > branches. > > > > > The patch has been verified in master. CI test may not be necessary. >=20 > In the general case where more than one critical bug may be fixed in a > stable branch, CI will help make sure that the combination of fixes > work together. For this first case, I agree that CI may not be = required. >=20 > > > > > 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/edk2-stable* > > > branch and a release is created on GitHub that summarizes the = set of > > > critical > > > fixes and the testing performed. > > > > > > Proposal: edk2-stable. > > > Example : edk2-stable201111.01 > > > > > It is OK to create new stable tag per the request. The platform can = use > stable branch. >=20 > Thank you. I will start work on a patch for review. >=20 > > > > Besides, there are few new issues. I have cancelled the bug triage = meeting. > > > > Thanks > > Liming > > > 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 > >