From: "Michael D Kinney" <michael.d.kinney@intel.com>
To: gaoliming <gaoliming@byosoft.com.cn>,
"devel@edk2.groups.io" <devel@edk2.groups.io>,
"rfc@edk2.groups.io" <rfc@edk2.groups.io>,
"'Andrew Fish'" <afish@apple.com>,
'Leif Lindholm' <leif@nuviainc.com>,
"lersek@redhat.com" <lersek@redhat.com>,
'Sean Brogan' <sean.brogan@microsoft.com>,
'Bret Barkelew' <Bret.Barkelew@microsoft.com>,
"Kinney, Michael D" <michael.d.kinney@intel.com>
Subject: Re: [RFC V2] Create supported branch from edk2-stable* tag (Required to address critical bug BZ3111)
Date: Wed, 16 Dec 2020 02:51:34 +0000 [thread overview]
Message-ID: <BL0PR11MB323602A9FAD7747660DB8D79D2C50@BL0PR11MB3236.namprd11.prod.outlook.com> (raw)
In-Reply-To: <005201d6d349$6f72b4b0$4e581e10$@byosoft.com.cn>
> -----Original Message-----
> From: gaoliming <gaoliming@byosoft.com.cn>
> Sent: Tuesday, December 15, 2020 5:19 PM
> To: Kinney, Michael D <michael.d.kinney@intel.com>; devel@edk2.groups.io; rfc@edk2.groups.io; 'Andrew Fish'
> <afish@apple.com>; 'Leif Lindholm' <leif@nuviainc.com>; lersek@redhat.com; 'Sean Brogan' <sean.brogan@microsoft.com>;
> 'Bret Barkelew' <Bret.Barkelew@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@intel.com>
> > 发送时间: 2020年12月16日 8:25
> > 收件人: devel@edk2.groups.io; rfc@edk2.groups.io;
> > gaoliming@byosoft.com.cn; Andrew Fish (afish@apple.com)
> > <afish@apple.com>; Leif Lindholm <leif@nuviainc.com>; Laszlo Ersek
> > <lersek@redhat.com> (lersek@redhat.com) <lersek@redhat.com>; 'Sean
> > Brogan' <sean.brogan@microsoft.com>; 'Bret Barkelew'
> > <Bret.Barkelew@microsoft.com>; Kinney, Michael D
> > <michael.d.kinney@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
>
next prev parent reply other threads:[~2020-12-16 2:51 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-12-16 0:24 [RFC V2] Create supported branch from edk2-stable* tag (Required to address critical bug BZ3111) Michael D Kinney
2020-12-16 1:18 ` 回复: " gaoliming
2020-12-16 2:51 ` Michael D Kinney [this message]
2020-12-17 2:13 ` gaoliming
2020-12-17 13:49 ` Laszlo Ersek
2020-12-17 18:46 ` [EXTERNAL] " Bret Barkelew
2020-12-19 1:54 ` [edk2-rfc] " Michael D Kinney
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-list from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=BL0PR11MB323602A9FAD7747660DB8D79D2C50@BL0PR11MB3236.namprd11.prod.outlook.com \
--to=devel@edk2.groups.io \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox