Date
1 - 7 of 7
[RFC] 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.
Proposal: stable/edk2-stable*
Example: stable/edk2-stable202011
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
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/edk2-stable*
Example: stable/edk2-stable202011
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
Leif Lindholm <leif@...>
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:
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
Best Regards,
Leif
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,For the bikeshedding part, if we're doing the branches, I support
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/edk2-stable*
Example: stable/edk2-stable202011
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.This would of course mandate the use of 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.Sounds good to me.
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
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
Michael D Kinney
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
toggle quoted message
Show quoted text
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,For the bikeshedding part, if we're doing the branches, I support
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/edk2-stable*
Example: stable/edk2-stable202011
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/2020112) CI requirements for supported branches.This would of course mandate the use of 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.Sounds good to me.
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
Best Regards,
LeifPlease 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
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
- 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,For the bikeshedding part, if we're doing the branches, I support
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
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/2020112) CI requirements for supported branches.This would of course mandate the use of 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.Sounds good to me.
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
Best Regards,
LeifPlease 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
Leif Lindholm <leif@...>
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 message
Show quoted text
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,For the bikeshedding part, if we're doing the branches, I support
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
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/2020112) CI requirements for supported branches.This would of course mandate the use of 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.Sounds good to me.
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
Best Regards,
LeifPlease 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
Michael D Kinney
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 message
Show quoted text
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
-----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 moreD<mailto:michael.d.kinney@...>
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, MichaelCc: devel@edk2.groups.io<mailto:devel@edk2.groups.io>; gaoliming@...<mailto:gaoliming@...>; AndrewFish (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 bugBZ3111)<afish@...>;
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@...)'BretLaszlo Ersek <lersek@...> (lersek@...) <lersek@...>; 'Sean Brogan' <sean.brogan@...>;https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbugzilla.tianocore.org%2Fshow_bug.cgi%3Fid%3D3111&;daBarkelew' <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
ta=04%7C01%7CBret.Barkelew%40microsoft.com%7C36133f4be9b24fbec5ca08d8a12b4024%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7
C637436554422046735%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&
sdata=EZCqLKBAXKgq8J40GFynYtqYIyhUpU7MIlT7wT4Cs9w%3D&reserved=0https://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=0https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Ftianocore%2Fedk2%2Fpull%2F1226%2Fcommits%2F
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.
893cfe2847b83da74f53858d6acaa15a348bad7c&data=04%7C01%7CBret.Barkelew%40microsoft.com%7C36133f4be9b24fbec5ca08d8a12b40
24%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637436554422056729%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2l
uMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=RiNVhyT3fmoVRtLP0fJqbuP1Ow26tDM31J1O6%2B01wMs%3D&reserved=0https://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=0For the bikeshedding part, if we're doing the branches, I support
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
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/2020112) CI requirements for supported branches.This would of course mandate the use of 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.Sounds good to me.
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
Best Regards,
LeifPlease 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