[edk2-devel] [RFC V2] Create supported branch from edk2-stable* tag (Required to address critical bug BZ3111)

[Michael D Kinney]

> -----Original Message-----
> From: gaoliming <gaoliming at byosoft.com.cn>
> Sent: Tuesday, December 15, 2020 5:19 PM
> To: Kinney, Michael D <michael.d.kinney at intel.com>; devel at edk2.groups.io; rfc at edk2.groups.io; 'Andrew Fish'
> <afish at apple.com>; 'Leif Lindholm' <leif at nuviainc.com>; lersek at redhat.com; 'Sean Brogan' <sean.brogan at microsoft.com>;
> 'Bret Barkelew' <Bret.Barkelew at microsoft.com>
> Subject: 回复: [RFC V2] Create supported branch from edk2-stable* tag (Required to address critical bug BZ3111)
> 
> Mike:
> 
> > -----邮件原件-----
> > 发件人: Kinney, Michael D <michael.d.kinney at intel.com>
> > 发送时间: 2020年12月16日 8:25
> > 收件人: devel at edk2.groups.io; rfc at edk2.groups.io;
> > gaoliming at byosoft.com.cn; Andrew Fish (afish at apple.com)
> > <afish at apple.com>; Leif Lindholm <leif at nuviainc.com>; Laszlo Ersek
> > <lersek at redhat.com> (lersek at redhat.com) <lersek at redhat.com>; 'Sean
> > Brogan' <sean.brogan at microsoft.com>; 'Bret Barkelew'
> > <Bret.Barkelew at microsoft.com>; Kinney, Michael D
> > <michael.d.kinney at intel.com>
> > 主题: [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=3111
> >     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.


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.

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.

> 
> > 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/<YYYY><MM>
> >     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.

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.

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.

> 
> >
> > 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.

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.

> 
> > 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<YYYY><MM>.<XX>
> >    Example : edk2-stable201111.01
> >
> It is OK to create new stable tag per the request. The platform can use stable branch.

Thank you.  I will start work on a patch for review.

> 
> 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
> 



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#68930): https://edk2.groups.io/g/devel/message/68930
Mute This Topic: https://groups.io/mt/78992819/1813853
Group Owner: devel+owner at edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [edk2-devel-archive at redhat.com]
-=-=-=-=-=-=-=-=-=-=-=-