Date   

回复: [edk2-devel] [edk2-rfc] [RFC] UnitTestFrameworkPkg cmocka submodule alternatives

gaoliming
 

Rebecca:
My new mail address is Liming Gao <gaoliming@byosoft.com.cn>. It has updated in Maintainers.txt.

Thanks
Liming

-----邮件原件-----
发件人: bounce+27952+69347+4905953+8761045@groups.io
<bounce+27952+69347+4905953+8761045@groups.io> 代表 Rebecca Cran
发送时间: 2020年12月22日 4:45
收件人: rfc@edk2.groups.io; michael.d.kinney@intel.com; gaoliming
<gaoliming@byosoft.com.cn>; devel@edk2.groups.io; 'Bret Barkelew'
<Bret.Barkelew@microsoft.com>; 'Laszlo Ersek' <lersek@redhat.com>; 'Gao,
Liming' <liming.gao@intel.com>
主题: Re: [edk2-devel] [edk2-rfc] [RFC] UnitTestFrameworkPkg cmocka
submodule alternatives

On 12/21/20 1:42 PM, Rebecca Cran wrote:
On 12/21/20 1:14 PM, Michael D Kinney wrote:
Rebecca,

Are you ok with using a GitHub mirror?
Yes, that's fine with me.
By the way, I've started getting bounces from Liming's Intel email address.

--
Rebecca Cran





Re: [edk2-devel] [edk2-rfc] [RFC] UnitTestFrameworkPkg cmocka submodule alternatives

Rebecca Cran
 

On 12/21/20 1:42 PM, Rebecca Cran wrote:
On 12/21/20 1:14 PM, Michael D Kinney wrote:
Rebecca,

Are you ok with using a GitHub mirror?
Yes, that's fine with me.
By the way, I've started getting bounces from Liming's Intel email address.

--
Rebecca Cran


Re: [edk2-devel] [edk2-rfc] [RFC] UnitTestFrameworkPkg cmocka submodule alternatives

Rebecca Cran
 

On 12/21/20 1:14 PM, Michael D Kinney wrote:
Rebecca,
Are you ok with using a GitHub mirror?
Yes, that's fine with me.

--
Rebecca Cran


Re: [edk2-devel] [edk2-rfc] [RFC] UnitTestFrameworkPkg cmocka submodule alternatives

Michael D Kinney
 

Rebecca,

Are you ok with using a GitHub mirror?

Mike

-----Original Message-----
From: gaoliming <gaoliming@byosoft.com.cn>
Sent: Sunday, December 20, 2020 5:18 PM
To: devel@edk2.groups.io; rebecca@bsdio.com; rfc@edk2.groups.io; Kinney, Michael D <michael.d.kinney@intel.com>; 'Bret
Barkelew' <Bret.Barkelew@microsoft.com>; 'Laszlo Ersek' <lersek@redhat.com>; 'Gao, Liming' <liming.gao@intel.com>
Subject: 回复: [edk2-devel] [edk2-rfc] [RFC] UnitTestFrameworkPkg cmocka submodule alternatives

I also prefer to fetch all submodules from github. Then, all git repos will have the same behavior.

Thanks
Liming
-----邮件原件-----
发件人: bounce+27952+69261+4905953+8761045@groups.io
<bounce+27952+69261+4905953+8761045@groups.io> 代表 Rebecca Cran
发送时间: 2020年12月20日 9:06
收件人: rfc@edk2.groups.io; michael.d.kinney@intel.com;
devel@edk2.groups.io; 'Bret Barkelew' <Bret.Barkelew@microsoft.com>;
Laszlo Ersek <lersek@redhat.com>; Gao, Liming <liming.gao@intel.com>
主题: Re: [edk2-devel] [edk2-rfc] [RFC] UnitTestFrameworkPkg cmocka
submodule alternatives

On 12/19/20 11:58 AM, Michael D Kinney wrote:
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-sync

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://github.com/mdkinney/mirror-cmocka

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://github.com/mdkinney/mirror-cmocka/blob/repo-sync/.github/workflo
ws/repo-sync.yml

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.
I'd suggest just using the Gitlab mirror. Unlike cryptomilk.org, Gitlab
should be just as reliable as Github and won't introduce another
potential failure point.

--
Rebecca Cran





回复: [edk2-devel] [edk2-rfc] [RFC] UnitTestFrameworkPkg cmocka submodule alternatives

gaoliming
 

I also prefer to fetch all submodules from github. Then, all git repos will have the same behavior.

Thanks
Liming

-----邮件原件-----
发件人: bounce+27952+69261+4905953+8761045@groups.io
<bounce+27952+69261+4905953+8761045@groups.io> 代表 Rebecca Cran
发送时间: 2020年12月20日 9:06
收件人: rfc@edk2.groups.io; michael.d.kinney@intel.com;
devel@edk2.groups.io; 'Bret Barkelew' <Bret.Barkelew@microsoft.com>;
Laszlo Ersek <lersek@redhat.com>; Gao, Liming <liming.gao@intel.com>
主题: Re: [edk2-devel] [edk2-rfc] [RFC] UnitTestFrameworkPkg cmocka
submodule alternatives

On 12/19/20 11:58 AM, Michael D Kinney wrote:
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-sync

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://github.com/mdkinney/mirror-cmocka

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://github.com/mdkinney/mirror-cmocka/blob/repo-sync/.github/workflo
ws/repo-sync.yml

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.
I'd suggest just using the Gitlab mirror. Unlike cryptomilk.org, Gitlab
should be just as reliable as Github and won't introduce another
potential failure point.

--
Rebecca Cran





回复: [edk2-rfc] [RFC V3] Create supported branch from edk2-stable* tag (Required to address critical bug BZ3111)

gaoliming
 

Mike:
It is OK to me. I have no other comments.

Thanks
Liming

-----邮件原件-----
发件人: bounce+34240+470+4905953+8776774@groups.io
<bounce+34240+470+4905953+8776774@groups.io> 代表 Michael D
Kinney
发送时间: 2020年12月19日 10:03
收件人: rfc@edk2.groups.io; devel@edk2.groups.io; Kinney, Michael D
<michael.d.kinney@intel.com>
主题: [edk2-rfc] [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/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



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.



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: [RFC] UnitTestFrameworkPkg cmocka submodule alternatives

Rebecca Cran
 

On 12/19/20 11:58 AM, Michael D Kinney wrote:
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-sync
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://github.com/mdkinney/mirror-cmocka
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://github.com/mdkinney/mirror-cmocka/blob/repo-sync/.github/workflows/repo-sync.yml
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.
I'd suggest just using the Gitlab mirror. Unlike cryptomilk.org, Gitlab should be just as reliable as Github and won't introduce another potential failure point.

--
Rebecca Cran


Re: [RFC] UnitTestFrameworkPkg cmocka submodule alternatives

Bret Barkelew <bret.barkelew@...>
 

I like it.

- Bret

From: Kinney, Michael D<mailto:michael.d.kinney@intel.com>
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@microsoft.com>; Laszlo Ersek <lersek@redhat.com> (lersek@redhat.com)<mailto:lersek@redhat.com>; liming.gao<mailto:liming.gao@intel.com>
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&amp;sdata=AX2EFVoGvtYoOZRtyFjwwTRbZkmQMgOCnjNNhWot7eo%3D&amp;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&amp;sdata=U7ThFHC2fsgO9rVTNre3b0dI23b1Iudi1tw%2FjiFEdZc%3D&amp;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&amp;sdata=CuxE3Ljy2M7APvXfnuOqb6YPnFCX%2FUkDxsiIGEUHcvY%3D&amp;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@intel.com>
Sent: Wednesday, December 16, 2020 10:46 AM
To: rfc@edk2.groups.io; devel@edk2.groups.io; Kinney, Michael D <michael.d.kinney@intel.com>; 'Bret Barkelew'
<Bret.Barkelew@microsoft.com>
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&amp;sdata=m4tHEei6OQUwJu6jcldgxycoBJoajqPb9o5aKTDra%2F0%3D&amp;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&amp;sdata=19d9nV6kG4FQE3GC3ZzDTmE6%2F7EjNdMMWM%2BbSGT6bSI%3D&amp;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&amp;sdata=xgErAgcMsMSKbrLZB9kgCHHl3r%2FzJM%2FJy6jhxpi0ObY%3D&amp;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&amp;sdata=Nyx8mBIwNxMEu4SdHYGiQhBGcpAPxxPHXBgI%2BM0CIU0%3D&amp;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&amp;sdata=19d9nV6kG4FQE3GC3ZzDTmE6%2F7EjNdMMWM%2BbSGT6bSI%3D&amp;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

Michael D Kinney
 

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

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://github.com/mdkinney/mirror-cmocka

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://github.com/mdkinney/mirror-cmocka/blob/repo-sync/.github/workflows/repo-sync.yml

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@intel.com>
Sent: Wednesday, December 16, 2020 10:46 AM
To: rfc@edk2.groups.io; devel@edk2.groups.io; Kinney, Michael D <michael.d.kinney@intel.com>; 'Bret Barkelew'
<Bret.Barkelew@microsoft.com>
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)

Michael D Kinney
 

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.



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)

Michael D Kinney
 

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

-----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@redhat.com>; Kinney, Michael D <michael.d.kinney@intel.com>; 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>; Sean Brogan <sean.brogan@microsoft.com>
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@redhat.com>
Sent: Thursday, December 17, 2020 5:50 AM
To: Kinney, Michael D<mailto:michael.d.kinney@intel.com>; devel@edk2.groups.io<mailto:devel@edk2.groups.io>;
rfc@edk2.groups.io<mailto:rfc@edk2.groups.io>; gaoliming@byosoft.com.cn<mailto:gaoliming@byosoft.com.cn>; Andrew Fish
(afish@apple.com)<mailto:afish@apple.com>; Leif Lindholm<mailto:leif@nuviainc.com>; Sean
Brogan<mailto:sean.brogan@microsoft.com>; Bret Barkelew<mailto:Bret.Barkelew@microsoft.com>
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&amp;
sdata=wE%2B9eA3XrRxS58KUk6DbFZmvX9nvmWopzGoVRN5713k%3D&amp;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&amp;sdata=
MnXglF%2FvtUDAouXJvBUIRFq7TuPL2dKXohXwcEuY3zc%3D&amp;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&amp;data=04%7C01%7Cbret.barkelew%40microsoft.com%7C092cd97468a645f68e4308d8a292a6
36%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637438098026646126%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2l
uMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=h19eR7KFYlerrva%2FVGMDb7DMVIUihINgAlOh96Hb2xI%3D&amp;reserved=0
https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Ftianocore%2Fedk2%2Fpull%2F1226%2Fcommits%2F
16491ba6a6e9a91cedeeed45bc0fbdfde49f7968&amp;data=04%7C01%7Cbret.barkelew%40microsoft.com%7C092cd97468a645f68e4308d8a292a6
36%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637438098026656126%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2l
uMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=8nCkmGD5jRyfrsMID0ESAcUb8plWrRkFafvhPiS2Zo8%3D&amp;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&amp;data=04%7C01%7Cbret.barkelew%40microsoft.com%7C092cd97468a645f68e4308d8a292a636%7C72f988bf86f1
41af91ab2d7cd011db47%7C1%7C0%7C637438098026656126%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1h
aWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=bOmSbEHuU%2BqLr3mdmhP%2Foq%2BR7yy%2BVNUWbG367yhFwQE%3D&amp;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)

gaoliming
 

Mike:

-----邮件原件-----
发件人: Kinney, Michael D <michael.d.kinney@intel.com>
发送时间: 2020年12月16日 10:52
收件人: gaoliming <gaoliming@byosoft.com.cn>; 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>; Kinney, Michael D
<michael.d.kinney@intel.com>
主题: RE: [RFC V2] Create supported branch from edk2-stable* tag (Required
to address critical bug BZ3111)

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

gaoliming
 

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

-----邮件原件-----
发件人: 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@intel.com>; 'Bret Barkelew'
<Bret.Barkelew@microsoft.com>
主题: [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)

gaoliming
 

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.

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@redhat.com>
Sent: Thursday, December 17, 2020 5:50 AM
To: Kinney, Michael D<mailto:michael.d.kinney@intel.com>; devel@edk2.groups.io<mailto:devel@edk2.groups.io>; rfc@edk2.groups.io<mailto:rfc@edk2.groups.io>; gaoliming@byosoft.com.cn<mailto:gaoliming@byosoft.com.cn>; Andrew Fish (afish@apple.com)<mailto:afish@apple.com>; Leif Lindholm<mailto:leif@nuviainc.com>; Sean Brogan<mailto:sean.brogan@microsoft.com>; Bret Barkelew<mailto:Bret.Barkelew@microsoft.com>
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&amp;sdata=wE%2B9eA3XrRxS58KUk6DbFZmvX9nvmWopzGoVRN5713k%3D&amp;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&amp;sdata=MnXglF%2FvtUDAouXJvBUIRFq7TuPL2dKXohXwcEuY3zc%3D&amp;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&amp;sdata=h19eR7KFYlerrva%2FVGMDb7DMVIUihINgAlOh96Hb2xI%3D&amp;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&amp;sdata=8nCkmGD5jRyfrsMID0ESAcUb8plWrRkFafvhPiS2Zo8%3D&amp;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&amp;sdata=bOmSbEHuU%2BqLr3mdmhP%2Foq%2BR7yy%2BVNUWbG367yhFwQE%3D&amp;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@nuviainc.com>
Sent: Thursday, December 17, 2020 8:01 AM
To: rfc@edk2.groups.io<mailto:rfc@edk2.groups.io>; lersek@redhat.com<mailto:lersek@redhat.com>; Kinney, Michael D<mailto:michael.d.kinney@intel.com>; devel@edk2.groups.io<mailto:devel@edk2.groups.io>; Bret Barkelew<mailto:Bret.Barkelew@microsoft.com>
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&amp;sdata=oOtke9Pjf8TFVV2D0nv1xW%2B2a9sBsXgbFo1A9fodooc%3D&amp;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&amp;sdata=RssBVgGe3ryeIudu%2Fg0WEEIyyUzkNo5mUBiXw3TCqT0%3D&amp;reserved=0

--
Rebecca Cran


Re: [RFC] UnitTestFrameworkPkg cmocka submodule alternatives

Rebecca Cran
 

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

Laszlo Ersek
 

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

Laszlo Ersek
 

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)

Laszlo Ersek
 

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

261 - 280 of 738