|
Re: [RFC] UnitTestFrameworkPkg cmocka submodule alternatives
Bret Barkelew <bret.barkelew@...>
I like it. - Bret From: Kinney, Michael D<mailto:michael.d.kinney@...> Sent: Saturday, December 19, 2020 10:59 AM To: rfc@edk2.groups.io<mailto:rfc@edk2.groups.io>; devel@edk2.groups.io<mailto:devel@edk2.groups.io>; Bret Barkelew<mailto:Bret.Barkelew@...>; Laszlo Ersek <lersek@...> (lersek@...)<mailto:lersek@...>; liming.gao<mailto:liming.gao@...> Subject: [EXTERNAL] RE: [RFC] UnitTestFrameworkPkg cmocka submodule alternatives Hello, There have been a few suggestions to create a mirror of cmocka in TianoCore org in GitHub. I have found a GitHub action that can do a repo sync. https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fmarketplace%2Factions%2Fgithub-repo-sync&;data=04%7C01%7CBret.Barkelew%40microsoft.com%7C92da18aaec1443463b2508d8a45023a2%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637440011398666049%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=AX2EFVoGvtYoOZRtyFjwwTRbZkmQMgOCnjNNhWot7eo%3D&reserved=0 I have created a temporary mirror of cmocka in my personal GitHub area that uses this GitHub action to sync all branches and all tags once a day. https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fmdkinney%2Fmirror-cmocka&;data=04%7C01%7CBret.Barkelew%40microsoft.com%7C92da18aaec1443463b2508d8a45023a2%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637440011398666049%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=U7ThFHC2fsgO9rVTNre3b0dI23b1Iudi1tw%2FjiFEdZc%3D&reserved=0 Here is the GitHub workflow file. It must be in the default branch for the repo using a branch name that is not present in the repo being mirrored. In this case, I used a branch name of 'repo-sync'. https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fmdkinney%2Fmirror-cmocka%2Fblob%2Frepo-sync%2F.github%2Fworkflows%2Frepo-sync.yml&;data=04%7C01%7CBret.Barkelew%40microsoft.com%7C92da18aaec1443463b2508d8a45023a2%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637440011398666049%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=CuxE3Ljy2M7APvXfnuOqb6YPnFCX%2FUkDxsiIGEUHcvY%3D&reserved=0 Please provide feedback on this approach. If we like this approach, then I suggest we create a new repo in TianoCore called edk2-cmocka that is a mirror that is synced once a day and we update the cmocka submodule in the edk2 repo to use edk2-cmocka. Best regards, Mike -----Original Message-----
From: Kinney, Michael D <michael.d.kinney@...>
Sent: Wednesday, December 16, 2020 10:46 AM
To: rfc@edk2.groups.io; devel@edk2.groups.io; Kinney, Michael D <michael.d.kinney@...>; 'Bret Barkelew'
<Bret.Barkelew@...>
Subject: [RFC] UnitTestFrameworkPkg cmocka submodule alternatives
Hello,
We have had at least three incidents in the last year where the link to the
cmocka submodule in the UnitTestFrameworkPkg has not been available, and this
impacted the EDK II CI system. The following submodule link is the one that
is not reliable:
https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgit.cryptomilk.org%2Fprojects%2Fcmocka.git&;data=04%7C01%7CBret.Barkelew%40microsoft.com%7C92da18aaec1443463b2508d8a45023a2%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637440011398666049%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=m4tHEei6OQUwJu6jcldgxycoBJoajqPb9o5aKTDra%2F0%3D&reserved=0
We have identified two potential mirrors of this repo:
https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fneverware-mirrors%2Fcmocka.git&;data=04%7C01%7CBret.Barkelew%40microsoft.com%7C92da18aaec1443463b2508d8a45023a2%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637440011398676045%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=19d9nV6kG4FQE3GC3ZzDTmE6%2F7EjNdMMWM%2BbSGT6bSI%3D&reserved=0
https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitlab.com%2Fcmocka%2Fcmocka.git&;data=04%7C01%7CBret.Barkelew%40microsoft.com%7C92da18aaec1443463b2508d8a45023a2%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637440011398676045%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=xgErAgcMsMSKbrLZB9kgCHHl3r%2FzJM%2FJy6jhxpi0ObY%3D&reserved=0
The following patch provided a temporary fix for the EDK II CI agents, but
does not help other consumers of the edk2 repository.
https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Ftianocore%2Fedk2%2Fcommit%2Fbe746104d1766a8c363e74d6063144657820d688&;data=04%7C01%7CBret.Barkelew%40microsoft.com%7C92da18aaec1443463b2508d8a45023a2%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637440011398676045%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=Nyx8mBIwNxMEu4SdHYGiQhBGcpAPxxPHXBgI%2BM0CIU0%3D&reserved=0
I have seen one suggestion that TianoCore create its own
mirror of cmocka. This does require monitoring and maintenance
by the TianoCore community. I would prefer to use a well
maintained mirror in github as long as we do not observe any
issues with the support of that mirror.
I propose we update the submodule in the UnitTestFrameworkPkg
to use the https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fneverware-mirrors%2Fcmocka.git&;data=04%7C01%7CBret.Barkelew%40microsoft.com%7C92da18aaec1443463b2508d8a45023a2%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637440011398676045%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=19d9nV6kG4FQE3GC3ZzDTmE6%2F7EjNdMMWM%2BbSGT6bSI%3D&reserved=0 mirror.
By using a mirror in github, we remove one external dependency.
Please provide feedback and comments on this proposal. If there
are no objections, then we will proceed with a patch review for
this update.
Thanks,
Mike
|
|
|
Re: [RFC] UnitTestFrameworkPkg cmocka submodule alternatives
Hello, There have been a few suggestions to create a mirror of cmocka in TianoCore org in GitHub. I have found a GitHub action that can do a repo sync. https://github.com/marketplace/actions/github-repo-syncI have created a temporary mirror of cmocka in my personal GitHub area that uses this GitHub action to sync all branches and all tags once a day. https://github.com/mdkinney/mirror-cmockaHere is the GitHub workflow file. It must be in the default branch for the repo using a branch name that is not present in the repo being mirrored. In this case, I used a branch name of 'repo-sync'. https://github.com/mdkinney/mirror-cmocka/blob/repo-sync/.github/workflows/repo-sync.ymlPlease provide feedback on this approach. If we like this approach, then I suggest we create a new repo in TianoCore called edk2-cmocka that is a mirror that is synced once a day and we update the cmocka submodule in the edk2 repo to use edk2-cmocka. Best regards, Mike
-----Original Message-----
From: Kinney, Michael D <michael.d.kinney@...>
Sent: Wednesday, December 16, 2020 10:46 AM
To: rfc@edk2.groups.io; devel@edk2.groups.io; Kinney, Michael D <michael.d.kinney@...>; 'Bret Barkelew'
<Bret.Barkelew@...>
Subject: [RFC] UnitTestFrameworkPkg cmocka submodule alternatives
Hello,
We have had at least three incidents in the last year where the link to the
cmocka submodule in the UnitTestFrameworkPkg has not been available, and this
impacted the EDK II CI system. The following submodule link is the one that
is not reliable:
https://git.cryptomilk.org/projects/cmocka.git
We have identified two potential mirrors of this repo:
https://github.com/neverware-mirrors/cmocka.git
https://gitlab.com/cmocka/cmocka.git
The following patch provided a temporary fix for the EDK II CI agents, but
does not help other consumers of the edk2 repository.
https://github.com/tianocore/edk2/commit/be746104d1766a8c363e74d6063144657820d688
I have seen one suggestion that TianoCore create its own
mirror of cmocka. This does require monitoring and maintenance
by the TianoCore community. I would prefer to use a well
maintained mirror in github as long as we do not observe any
issues with the support of that mirror.
I propose we update the submodule in the UnitTestFrameworkPkg
to use the https://github.com/neverware-mirrors/cmocka.git mirror.
By using a mirror in github, we remove one external dependency.
Please provide feedback and comments on this proposal. If there
are no objections, then we will proceed with a patch review for
this update.
Thanks,
Mike
|
|
|
[RFC V3] 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/1226This 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/893cfe2847b83da74f53858d6acaa15a348bad7c https://github.com/tianocore/edk2/pull/1226/commits/16491ba6a6e9a91cedeeed45bc0fbdfde49f7968The 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. Branch Proposal: stable/<YYYY><MM> Branch Example: stable/202011 2) CI requirements for supported branches. Proposal: Update .azurepipelines yml files to trigger on stable/* branches, update .mergify configuration file to support merging of stable/* branches, and update GitHub branch protection settings to protect stable/* branches. 3) A stable/* branch is only supported until the next edk2-stable tag release. 4) Release requirements for supported branches. Proposal: If there are a significant number of critical fixes applied to a 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/* branch and a release is created on GitHub that summarizes the set of critical fixes and the testing performed. Tag Proposal: edk2-stable<YYYY><MM>.<XX> Tag Example : edk2-stable202011.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. Thank you, Mike
|
|
|
Re: [EXTERNAL] Re: [RFC V2] Create supported branch from edk2-stable* tag (Required to address critical bug BZ3111)
I agree that the default policy is to only support a branch until the next
stable tag. My comments were only to address the potential for a request
after that defined support timeline. If a portion of the community wants
to do the work required to support past that point, then I doubt we would
reject the idea.
I will only document the default policy. Anything past that would have
to be raised as a new request.
Mike
toggle quoted messageShow quoted text
-----Original Message-----
From: rfc@edk2.groups.io <rfc@edk2.groups.io> On Behalf Of Bret Barkelew via groups.io
Sent: Thursday, December 17, 2020 10:46 AM
To: Laszlo Ersek <lersek@...>; Kinney, Michael D <michael.d.kinney@...>; devel@edk2.groups.io;
rfc@edk2.groups.io; gaoliming@...; Andrew Fish (afish@...) <afish@...>; Leif Lindholm
<leif@...>; Sean Brogan <sean.brogan@...>
Subject: Re: [edk2-rfc] [EXTERNAL] Re: [RFC V2] Create supported branch from edk2-stable* tag (Required to address
critical bug BZ3111)
“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.”
Seconded. We actually had to update our release process with this blurb recently:
https://microsoft.github.io/mu/How/release_process/#post-lts-and-archiving
- Bret
From: Laszlo Ersek<mailto:lersek@...>
Sent: Thursday, December 17, 2020 5:50 AM
To: Kinney, Michael D<mailto:michael.d.kinney@...>; devel@edk2.groups.io<mailto:devel@edk2.groups.io>;
rfc@edk2.groups.io<mailto:rfc@edk2.groups.io>; gaoliming@...<mailto:gaoliming@...>; Andrew Fish
(afish@...)<mailto:afish@...>; Leif Lindholm<mailto:leif@...>; Sean
Brogan<mailto:sean.brogan@...>; Bret Barkelew<mailto: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=https%3A%2F%2Fbugzilla.tianocore.org%2Fshow_bug.cgi%3Fid%3D3111&;da
ta=04%7C01%7Cbret.barkelew%40microsoft.com%7C092cd97468a645f68e4308d8a292a636%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7
C637438098026646126%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&
sdata=wE%2B9eA3XrRxS58KUk6DbFZmvX9nvmWopzGoVRN5713k%3D&reserved=0
https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Ftianocore%2Fedk2%2Fpull%2F1226&;data=04%
7C01%7Cbret.barkelew%40microsoft.com%7C092cd97468a645f68e4308d8a292a636%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C63743
8098026646126%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=
MnXglF%2FvtUDAouXJvBUIRFq7TuPL2dKXohXwcEuY3zc%3D&reserved=0
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://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Ftianocore%2Fedk2%2Fpull%2F1226%2Fcommits%2F
893cfe2847b83da74f53858d6acaa15a348bad7c&data=04%7C01%7Cbret.barkelew%40microsoft.com%7C092cd97468a645f68e4308d8a292a6
36%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637438098026646126%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2l
uMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=h19eR7KFYlerrva%2FVGMDb7DMVIUihINgAlOh96Hb2xI%3D&reserved=0
https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Ftianocore%2Fedk2%2Fpull%2F1226%2Fcommits%2F
16491ba6a6e9a91cedeeed45bc0fbdfde49f7968&data=04%7C01%7Cbret.barkelew%40microsoft.com%7C092cd97468a645f68e4308d8a292a6
36%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637438098026656126%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2l
uMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=8nCkmGD5jRyfrsMID0ESAcUb8plWrRkFafvhPiS2Zo8%3D&reserved=0
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
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.
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
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=https%3A%2F%2Fgit.qemu.org%2F%3Fp%3Dqemu.git%3Ba%3Dblob_plain%3Bf%3Ddo
cs%2Fdevel%2Fstable-
process.rst%3Bhb%3DHEAD&data=04%7C01%7Cbret.barkelew%40microsoft.com%7C092cd97468a645f68e4308d8a292a636%7C72f988bf86f1
41af91ab2d7cd011db47%7C1%7C0%7C637438098026656126%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1h
aWwiLCJXVCI6Mn0%3D%7C1000&sdata=bOmSbEHuU%2BqLr3mdmhP%2Foq%2BR7yy%2BVNUWbG367yhFwQE%3D&reserved=0
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
|
|
|
回复: [RFC V2] Create supported branch from edk2-stable* tag (Required to address critical bug BZ3111)
Mike: -----邮件原件-----
发件人: Kinney, Michael D <michael.d.kinney@...>
发送时间: 2020年12月16日 10:52
收件人: gaoliming <gaoliming@...>; devel@edk2.groups.io;
rfc@edk2.groups.io; 'Andrew Fish' <afish@...>; 'Leif Lindholm'
<leif@...>; lersek@...; 'Sean Brogan'
<sean.brogan@...>; 'Bret Barkelew'
<Bret.Barkelew@...>; Kinney, Michael D
<michael.d.kinney@...>
主题: RE: [RFC V2] Create supported branch from edk2-stable* tag (Required
to address critical bug BZ3111)
-----Original Message-----
From: gaoliming <gaoliming@...>
Sent: Tuesday, December 15, 2020 5:19 PM
To: Kinney, Michael D <michael.d.kinney@...>; devel@edk2.groups.io; rfc@edk2.groups.io; 'Andrew Fish'
<afish@...>; 'Leif Lindholm' <leif@...>; lersek@...; 'Sean Brogan' <sean.brogan@...>;
'Bret Barkelew' <Bret.Barkelew@...>
Subject: 回复: [RFC V2] Create supported branch from edk2-stable* tag (Required to address critical bug BZ3111)
Mike:
-----邮件原件-----
发件人: Kinney, Michael D <michael.d.kinney@...>
发送时间: 2020年12月16日 8:25
收件人: devel@edk2.groups.io; rfc@edk2.groups.io;
gaoliming@...; Andrew Fish (afish@...)
<afish@...>; Leif Lindholm <leif@...>; Laszlo Ersek
<lersek@...> (lersek@...) <lersek@...>; 'Sean
Brogan' <sean.brogan@...>; 'Bret Barkelew'
<Bret.Barkelew@...>; Kinney, Michael D
<michael.d.kinney@...>
主题: [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.
This case is clear. One commit is for the bug fix, another is for the unit test. 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/<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.
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. 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.
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
|
|
|
回复: [edk2-devel] [RFC] UnitTestFrameworkPkg cmocka submodule alternatives
Mike:
I review all submodules in edk2. They are all from github except for cmocka. So, I agree to use github mirror for cmocka.
Thanks
Liming
toggle quoted messageShow quoted text
-----邮件原件-----
发件人: bounce+27952+69010+4905953+8761045@groups.io
<bounce+27952+69010+4905953+8761045@groups.io> 代表 Michael D
Kinney
发送时间: 2020年12月17日 2:46
收件人: rfc@edk2.groups.io; devel@edk2.groups.io; Kinney, Michael D
<michael.d.kinney@...>; 'Bret Barkelew'
<Bret.Barkelew@...>
主题: [edk2-devel] [RFC] UnitTestFrameworkPkg cmocka submodule
alternatives
Hello,
We have had at least three incidents in the last year where the link to the
cmocka submodule in the UnitTestFrameworkPkg has not been available, and
this
impacted the EDK II CI system. The following submodule link is the one that
is not reliable:
https://git.cryptomilk.org/projects/cmocka.git
We have identified two potential mirrors of this repo:
https://github.com/neverware-mirrors/cmocka.git
https://gitlab.com/cmocka/cmocka.git
The following patch provided a temporary fix for the EDK II CI agents, but
does not help other consumers of the edk2 repository.
https://github.com/tianocore/edk2/commit/be746104d1766a8c363e74
d6063144657820d688
I have seen one suggestion that TianoCore create its own
mirror of cmocka. This does require monitoring and maintenance
by the TianoCore community. I would prefer to use a well
maintained mirror in github as long as we do not observe any
issues with the support of that mirror.
I propose we update the submodule in the UnitTestFrameworkPkg
to use the https://github.com/neverware-mirrors/cmocka.git mirror.
By using a mirror in github, we remove one external dependency.
Please provide feedback and comments on this proposal. If there
are no objections, then we will proceed with a patch review for
this update.
Thanks,
Mike
|
|
|
回复: [RFC V2] Create supported branch from edk2-stable* tag (Required to address critical bug BZ3111)
Mike: -----邮件原件-----
发件人: Kinney, Michael D <michael.d.kinney@...>
发送时间: 2020年12月16日 8:25
收件人: devel@edk2.groups.io; rfc@edk2.groups.io;
gaoliming@...; Andrew Fish (afish@...)
<afish@...>; Leif Lindholm <leif@...>; Laszlo Ersek
<lersek@...> (lersek@...) <lersek@...>; 'Sean
Brogan' <sean.brogan@...>; 'Bret Barkelew'
<Bret.Barkelew@...>; Kinney, Michael D
<michael.d.kinney@...>
主题: [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. 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.
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. 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. 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
|
|
|
Re: [EXTERNAL] Re: [RFC V2] Create supported branch from edk2-stable* tag (Required to address critical bug BZ3111)
Bret Barkelew <bret.barkelew@...>
“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.” Seconded. We actually had to update our release process with this blurb recently: https://microsoft.github.io/mu/How/release_process/#post-lts-and-archiving- Bret From: Laszlo Ersek<mailto:lersek@...> Sent: Thursday, December 17, 2020 5:50 AM To: Kinney, Michael D<mailto:michael.d.kinney@...>; devel@edk2.groups.io<mailto:devel@edk2.groups.io>; rfc@edk2.groups.io<mailto:rfc@edk2.groups.io>; gaoliming@...<mailto:gaoliming@...>; Andrew Fish (afish@...)<mailto:afish@...>; Leif Lindholm<mailto:leif@...>; Sean Brogan<mailto:sean.brogan@...>; Bret Barkelew<mailto: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=https%3A%2F%2Fbugzilla.tianocore.org%2Fshow_bug.cgi%3Fid%3D3111&;data=04%7C01%7Cbret.barkelew%40microsoft.com%7C092cd97468a645f68e4308d8a292a636%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637438098026646126%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=wE%2B9eA3XrRxS58KUk6DbFZmvX9nvmWopzGoVRN5713k%3D&reserved=0
https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Ftianocore%2Fedk2%2Fpull%2F1226&;data=04%7C01%7Cbret.barkelew%40microsoft.com%7C092cd97468a645f68e4308d8a292a636%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637438098026646126%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=MnXglF%2FvtUDAouXJvBUIRFq7TuPL2dKXohXwcEuY3zc%3D&reserved=0
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://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Ftianocore%2Fedk2%2Fpull%2F1226%2Fcommits%2F893cfe2847b83da74f53858d6acaa15a348bad7c&;data=04%7C01%7Cbret.barkelew%40microsoft.com%7C092cd97468a645f68e4308d8a292a636%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637438098026646126%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=h19eR7KFYlerrva%2FVGMDb7DMVIUihINgAlOh96Hb2xI%3D&reserved=0
https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Ftianocore%2Fedk2%2Fpull%2F1226%2Fcommits%2F16491ba6a6e9a91cedeeed45bc0fbdfde49f7968&;data=04%7C01%7Cbret.barkelew%40microsoft.com%7C092cd97468a645f68e4308d8a292a636%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637438098026656126%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=8nCkmGD5jRyfrsMID0ESAcUb8plWrRkFafvhPiS2Zo8%3D&reserved=0
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
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.
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
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=https%3A%2F%2Fgit.qemu.org%2F%3Fp%3Dqemu.git%3Ba%3Dblob_plain%3Bf%3Ddocs%2Fdevel%2Fstable-process.rst%3Bhb%3DHEAD&;data=04%7C01%7Cbret.barkelew%40microsoft.com%7C092cd97468a645f68e4308d8a292a636%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637438098026656126%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=bOmSbEHuU%2BqLr3mdmhP%2Foq%2BR7yy%2BVNUWbG367yhFwQE%3D&reserved=0 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
|
|
|
Re: [EXTERNAL] Re: [edk2-rfc] [RFC] UnitTestFrameworkPkg cmocka submodule alternatives
Bret Barkelew <bret.barkelew@...>
My vote is to own a fork. I agree with Laszlo that it’s very low maintenance (may even be able to automate it with an existing DevOps pipeline to run every day) and gives us the most control of our destiny. - Bret From: Rebecca Cran<mailto:rebecca@...> Sent: Thursday, December 17, 2020 8:01 AM To: rfc@edk2.groups.io<mailto:rfc@edk2.groups.io>; lersek@...<mailto:lersek@...>; Kinney, Michael D<mailto:michael.d.kinney@...>; devel@edk2.groups.io<mailto:devel@edk2.groups.io>; Bret Barkelew<mailto:Bret.Barkelew@...> Subject: [EXTERNAL] Re: [edk2-rfc] [RFC] UnitTestFrameworkPkg cmocka submodule alternatives On 12/17/20 8:54 AM, Laszlo Ersek wrote: On 12/17/20 15:48, Laszlo Ersek wrote:
I don't know who or what the <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fneverware-mirrors&;data=04%7C01%7CBret.Barkelew%40microsoft.com%7C4cd7a0f805864468a2cb08d8a2a50fb8%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637438177109105172%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=oOtke9Pjf8TFVV2D0nv1xW%2B2a9sBsXgbFo1A9fodooc%3D&reserved=0>
organization is, and I'd prefer not fetching code from them automatically. I'm sorry, this was silly.
The whole point of git is "addressing by content". Our submodule
reference in edk2 makes us check out the cmocka tree at a known hash, so
where that comes from is totally irrelevant.
I'm OK with the proposal as posted. Also, apparently Neverware is part of Google: https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcloudreadykb.neverware.com%2Fs%2Farticle%2FNeverware-is-now-part-of-Google-FAQ&;data=04%7C01%7CBret.Barkelew%40microsoft.com%7C4cd7a0f805864468a2cb08d8a2a50fb8%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637438177109115169%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=RssBVgGe3ryeIudu%2Fg0WEEIyyUzkNo5mUBiXw3TCqT0%3D&reserved=0 -- Rebecca Cran
|
|
|
Re: [RFC] UnitTestFrameworkPkg cmocka submodule alternatives
Rebecca Cran <rebecca@...>
On 12/17/20 8:54 AM, Laszlo Ersek wrote: On 12/17/20 15:48, Laszlo Ersek wrote:
I don't know who or what the <https://github.com/neverware-mirrors>
organization is, and I'd prefer not fetching code from them automatically. I'm sorry, this was silly.
The whole point of git is "addressing by content". Our submodule
reference in edk2 makes us check out the cmocka tree at a known hash, so
where that comes from is totally irrelevant.
I'm OK with the proposal as posted. Also, apparently Neverware is part of Google: https://cloudreadykb.neverware.com/s/article/Neverware-is-now-part-of-Google-FAQ-- Rebecca Cran
|
|
|
Re: [RFC] UnitTestFrameworkPkg cmocka submodule alternatives
On 12/17/20 15:48, Laszlo Ersek wrote: I don't know who or what the <https://github.com/neverware-mirrors>
organization is, and I'd prefer not fetching code from them automatically. I'm sorry, this was silly. The whole point of git is "addressing by content". Our submodule reference in edk2 makes us check out the cmocka tree at a known hash, so where that comes from is totally irrelevant. I'm OK with the proposal as posted. Thanks & sorry again, Laszlo
|
|
|
Re: [RFC] UnitTestFrameworkPkg cmocka submodule alternatives
On 12/16/20 19:45, Michael D Kinney wrote: Hello,
We have had at least three incidents in the last year where the link to the
cmocka submodule in the UnitTestFrameworkPkg has not been available, and this
impacted the EDK II CI system. The following submodule link is the one that
is not reliable:
https://git.cryptomilk.org/projects/cmocka.git
We have identified two potential mirrors of this repo:
https://github.com/neverware-mirrors/cmocka.git
https://gitlab.com/cmocka/cmocka.git
The following patch provided a temporary fix for the EDK II CI agents, but
does not help other consumers of the edk2 repository.
https://github.com/tianocore/edk2/commit/be746104d1766a8c363e74d6063144657820d688
I have seen one suggestion that TianoCore create its own
mirror of cmocka. This does require monitoring and maintenance
by the TianoCore community. I would prefer to use a well
maintained mirror in github as long as we do not observe any
issues with the support of that mirror.
I propose we update the submodule in the UnitTestFrameworkPkg
to use the https://github.com/neverware-mirrors/cmocka.git mirror.
By using a mirror in github, we remove one external dependency.
Please provide feedback and comments on this proposal. If there
are no objections, then we will proceed with a patch review for
this update. We could create our own fork under the < https://github.com/tianocore> organization. It does not require much extra maintenance or monitoring, in my opinion. We only need to advance our fork to the actual master HEAD when we intend to advance our submodule reference in edk2 as well. As long as the submodule reference in edk2 does not move, the actual master HEAD of the cmocka project may very well be ahead of our fork (mirror), without causing issues. I don't know who or what the < https://github.com/neverware-mirrors> organization is, and I'd prefer not fetching code from them automatically. Thanks Laszlo
|
|
|
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://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/893cfe2847b83da74f53858d6acaa15a348bad7c
https://github.com/tianocore/edk2/pull/1226/commits/16491ba6a6e9a91cedeeed45bc0fbdfde49f7968
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
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.
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
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://git.qemu.org/?p=qemu.git;a=blob_plain;f=docs/devel/stable-process.rst;hb=HEAD 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
|
|
|
Re: [RFC] Create supported branch from edk2-stable* tag (Required to address critical bug BZ3111)
On 12/15/20 20:39, Leif Lindholm wrote: Makes sense. Let's go with the branch.
Mike: yes, that was what I was suggesting wrt cherry-picking and pushing. Sounds good to me as well, thanks! Laszlo
|
|
|
[RFC] UnitTestFrameworkPkg cmocka submodule alternatives
|
|
|
Re: [RFC V2] Create supported branch from edk2-stable* tag (Required to address critical bug BZ3111)
toggle quoted messageShow quoted text
-----Original Message-----
From: gaoliming <gaoliming@...>
Sent: Tuesday, December 15, 2020 5:19 PM
To: Kinney, Michael D <michael.d.kinney@...>; devel@edk2.groups.io; rfc@edk2.groups.io; 'Andrew Fish'
<afish@...>; 'Leif Lindholm' <leif@...>; lersek@...; 'Sean Brogan' <sean.brogan@...>;
'Bret Barkelew' <Bret.Barkelew@...>
Subject: 回复: [RFC V2] Create supported branch from edk2-stable* tag (Required to address critical bug BZ3111)
Mike:
-----邮件原件-----
发件人: Kinney, Michael D <michael.d.kinney@...>
发送时间: 2020年12月16日 8:25
收件人: devel@edk2.groups.io; rfc@edk2.groups.io;
gaoliming@...; Andrew Fish (afish@...)
<afish@...>; Leif Lindholm <leif@...>; Laszlo Ersek
<lersek@...> (lersek@...) <lersek@...>; 'Sean
Brogan' <sean.brogan@...>; 'Bret Barkelew'
<Bret.Barkelew@...>; Kinney, Michael D
<michael.d.kinney@...>
主题: [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
|
|
|
[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/1226This 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/893cfe2847b83da74f53858d6acaa15a348bad7c https://github.com/tianocore/edk2/pull/1226/commits/16491ba6a6e9a91cedeeed45bc0fbdfde49f7968The 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 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. 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 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
|
|
|
Re: [RFC] Create supported branch from edk2-stable* tag (Required to address critical bug BZ3111)
Hi Leif,
Thank you for the feedback.
I will send a revised RFC soon.
I will discuss with Liming in the Tianocore bug scrub this evening.
Mike
toggle quoted messageShow quoted text
-----Original Message-----
From: rfc@edk2.groups.io <rfc@edk2.groups.io> On Behalf Of Leif Lindholm
Sent: Tuesday, December 15, 2020 11:40 AM
To: Bret Barkelew <Bret.Barkelew@...>
Cc: Kinney, Michael D <michael.d.kinney@...>; rfc@edk2.groups.io; devel@edk2.groups.io; gaoliming@...;
Andrew Fish (afish@...) <afish@...>; Laszlo Ersek <lersek@...> (lersek@...) <lersek@...>;
Sean Brogan <sean.brogan@...>
Subject: Re: [edk2-rfc] [RFC] Create supported branch from edk2-stable* tag (Required to address critical bug BZ3111)
Makes sense. Let's go with the branch.
Mike: yes, that was what I was suggesting wrt cherry-picking and pushing.
Best Regards,
Leif
On Tue, Dec 15, 2020 at 19:06:21 +0000, Bret Barkelew wrote:
FWIW, we tried both branches and tags in Mu, and have 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
validation run), but our platform consumers have shown a preference
for just living on the stabilized branch.
- Bret
From: Kinney, Michael D<mailto:michael.d.kinney@...>
Sent: Tuesday, December 15, 2020 10:57 AM
To: rfc@edk2.groups.io<mailto:rfc@edk2.groups.io>; leif@...<mailto:leif@...>; Kinney, Michael D<mailto:michael.d.kinney@...>
Cc: devel@edk2.groups.io<mailto:devel@edk2.groups.io>; gaoliming@...<mailto:gaoliming@...>; Andrew Fish (afish@...)<mailto:afish@...>; Laszlo Ersek <lersek@...>
(lersek@...)<mailto:lersek@...>; Sean Brogan<mailto:sean.brogan@...>; Bret
Barkelew<mailto:Bret.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 that 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 new 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 use an edk2-stable*
tag with all the known critical bug fixes can pull the branch to get the latest fixes. Or select
a tag on the branch or a specific sha on the branch based on their platform 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 downstream.
I think between the CI use case and this downstream platform use case, a branch has more
advantages than a tag.
I am fine with removing the redundant use of 'stable' and 'edk2' in the branch 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@...>
Cc: devel@edk2.groups.io; rfc@edk2.groups.io; gaoliming@...; Andrew Fish (afish@...)
<afish@...>;
Laszlo Ersek <lersek@...> (lersek@...) <lersek@...>; 'Sean Brogan' <sean.brogan@...>;
'Bret
Barkelew' <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=https%3A%2F%2Fbugzilla.tianocore.org%2Fshow_bug.cgi%3Fid%3D3111&;da
ta=04%7C01%7CBret.Barkelew%40microsoft.com%7C36133f4be9b24fbec5ca08d8a12b4024%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7
C637436554422046735%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&
sdata=EZCqLKBAXKgq8J40GFynYtqYIyhUpU7MIlT7wT4Cs9w%3D&reserved=0
https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Ftianocore%2Fedk2%2Fpull%2F1226&;data=04%
7C01%7CBret.Barkelew%40microsoft.com%7C36133f4be9b24fbec5ca08d8a12b4024%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C63743
6554422056729%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=
pQG7sjlHRxwh5mugH3vNKoZt88b%2BD7W4YHspsdb%2BQZ8%3D&reserved=0
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://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Ftianocore%2Fedk2%2Fpull%2F1226%2Fcommits%2F
893cfe2847b83da74f53858d6acaa15a348bad7c&data=04%7C01%7CBret.Barkelew%40microsoft.com%7C36133f4be9b24fbec5ca08d8a12b40
24%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637436554422056729%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2l
uMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=RiNVhyT3fmoVRtLP0fJqbuP1Ow26tDM31J1O6%2B01wMs%3D&reserved=0
https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Ftianocore%2Fedk2%2Fpull%2F1226%2Fcommits%2F
16491ba6a6e9a91cedeeed45bc0fbdfde49f7968&data=04%7C01%7CBret.Barkelew%40microsoft.com%7C36133f4be9b24fbec5ca08d8a12b40
24%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637436554422056729%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2l
uMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=DpZO7U2yoqD%2BK%2F6OxIZoI%2FbIDMbtRr7UBMCBl9PxGkQ%3D&reserved=0
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/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 stable/* branches
and update GitHub settings so stable/* branches 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 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 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
|
|
|
Re: [RFC] Create supported branch from edk2-stable* tag (Required to address critical bug BZ3111)
Makes sense. Let's go with the branch.
Mike: yes, that was what I was suggesting wrt cherry-picking and pushing.
Best Regards,
Leif
toggle quoted messageShow quoted text
On Tue, Dec 15, 2020 at 19:06:21 +0000, Bret Barkelew wrote: FWIW, we tried both branches and tags in Mu, and have 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
validation run), but our platform consumers have shown a preference
for just living on the stabilized branch.
- Bret
From: Kinney, Michael D<mailto:michael.d.kinney@...>
Sent: Tuesday, December 15, 2020 10:57 AM
To: rfc@edk2.groups.io<mailto:rfc@edk2.groups.io>; leif@...<mailto:leif@...>; Kinney, Michael D<mailto:michael.d.kinney@...>
Cc: devel@edk2.groups.io<mailto:devel@edk2.groups.io>; gaoliming@...<mailto:gaoliming@...>; Andrew Fish (afish@...)<mailto:afish@...>; Laszlo Ersek <lersek@...> (lersek@...)<mailto:lersek@...>; Sean Brogan<mailto:sean.brogan@...>; Bret Barkelew<mailto:Bret.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 that 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 new 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 use an edk2-stable*
tag with all the known critical bug fixes can pull the branch to get the latest fixes. Or select
a tag on the branch or a specific sha on the branch based on their platform 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 downstream.
I think between the CI use case and this downstream platform use case, a branch has more
advantages than a tag.
I am fine with removing the redundant use of 'stable' and 'edk2' in the branch 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@...>
Cc: devel@edk2.groups.io; rfc@edk2.groups.io; gaoliming@...; Andrew Fish (afish@...) <afish@...>;
Laszlo Ersek <lersek@...> (lersek@...) <lersek@...>; 'Sean Brogan' <sean.brogan@...>; 'Bret
Barkelew' <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=https%3A%2F%2Fbugzilla.tianocore.org%2Fshow_bug.cgi%3Fid%3D3111&;data=04%7C01%7CBret.Barkelew%40microsoft.com%7C36133f4be9b24fbec5ca08d8a12b4024%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637436554422046735%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=EZCqLKBAXKgq8J40GFynYtqYIyhUpU7MIlT7wT4Cs9w%3D&reserved=0
https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Ftianocore%2Fedk2%2Fpull%2F1226&;data=04%7C01%7CBret.Barkelew%40microsoft.com%7C36133f4be9b24fbec5ca08d8a12b4024%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637436554422056729%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=pQG7sjlHRxwh5mugH3vNKoZt88b%2BD7W4YHspsdb%2BQZ8%3D&reserved=0
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://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Ftianocore%2Fedk2%2Fpull%2F1226%2Fcommits%2F893cfe2847b83da74f53858d6acaa15a348bad7c&;data=04%7C01%7CBret.Barkelew%40microsoft.com%7C36133f4be9b24fbec5ca08d8a12b4024%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637436554422056729%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=RiNVhyT3fmoVRtLP0fJqbuP1Ow26tDM31J1O6%2B01wMs%3D&reserved=0
https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Ftianocore%2Fedk2%2Fpull%2F1226%2Fcommits%2F16491ba6a6e9a91cedeeed45bc0fbdfde49f7968&;data=04%7C01%7CBret.Barkelew%40microsoft.com%7C36133f4be9b24fbec5ca08d8a12b4024%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637436554422056729%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=DpZO7U2yoqD%2BK%2F6OxIZoI%2FbIDMbtRr7UBMCBl9PxGkQ%3D&reserved=0
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/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 stable/* branches
and update GitHub settings so stable/* branches 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 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 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
|
|
|
Re: [RFC] Create supported branch from edk2-stable* tag (Required to address critical bug BZ3111)
Bret Barkelew <bret.barkelew@...>
FWIW, we tried both branches and tags in Mu, and have 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 validation run), but our platform consumers have shown a preference for just living on the stabilized branch. - Bret From: Kinney, Michael D<mailto:michael.d.kinney@...> Sent: Tuesday, December 15, 2020 10:57 AM To: rfc@edk2.groups.io<mailto:rfc@edk2.groups.io>; leif@...<mailto:leif@...>; Kinney, Michael D<mailto:michael.d.kinney@...> Cc: devel@edk2.groups.io<mailto:devel@edk2.groups.io>; gaoliming@...<mailto:gaoliming@...>; Andrew Fish (afish@...)<mailto:afish@...>; Laszlo Ersek <lersek@...> (lersek@...)<mailto:lersek@...>; Sean Brogan<mailto:sean.brogan@...>; Bret Barkelew<mailto:Bret.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 that 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 new 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 use an edk2-stable* tag with all the known critical bug fixes can pull the branch to get the latest fixes. Or select a tag on the branch or a specific sha on the branch based on their platform 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 downstream. I think between the CI use case and this downstream platform use case, a branch has more advantages than a tag. I am fine with removing the redundant use of 'stable' and 'edk2' in the branch 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@...>
Cc: devel@edk2.groups.io; rfc@edk2.groups.io; gaoliming@...; Andrew Fish (afish@...) <afish@...>;
Laszlo Ersek <lersek@...> (lersek@...) <lersek@...>; 'Sean Brogan' <sean.brogan@...>; 'Bret
Barkelew' <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=https%3A%2F%2Fbugzilla.tianocore.org%2Fshow_bug.cgi%3Fid%3D3111&;data=04%7C01%7CBret.Barkelew%40microsoft.com%7C36133f4be9b24fbec5ca08d8a12b4024%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637436554422046735%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=EZCqLKBAXKgq8J40GFynYtqYIyhUpU7MIlT7wT4Cs9w%3D&reserved=0
https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Ftianocore%2Fedk2%2Fpull%2F1226&;data=04%7C01%7CBret.Barkelew%40microsoft.com%7C36133f4be9b24fbec5ca08d8a12b4024%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637436554422056729%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=pQG7sjlHRxwh5mugH3vNKoZt88b%2BD7W4YHspsdb%2BQZ8%3D&reserved=0
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://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Ftianocore%2Fedk2%2Fpull%2F1226%2Fcommits%2F893cfe2847b83da74f53858d6acaa15a348bad7c&;data=04%7C01%7CBret.Barkelew%40microsoft.com%7C36133f4be9b24fbec5ca08d8a12b4024%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637436554422056729%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=RiNVhyT3fmoVRtLP0fJqbuP1Ow26tDM31J1O6%2B01wMs%3D&reserved=0
https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Ftianocore%2Fedk2%2Fpull%2F1226%2Fcommits%2F16491ba6a6e9a91cedeeed45bc0fbdfde49f7968&;data=04%7C01%7CBret.Barkelew%40microsoft.com%7C36133f4be9b24fbec5ca08d8a12b4024%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637436554422056729%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=DpZO7U2yoqD%2BK%2F6OxIZoI%2FbIDMbtRr7UBMCBl9PxGkQ%3D&reserved=0
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/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 stable/* branches
and update GitHub settings so stable/* branches 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 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 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
|
|
|
