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

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



-----Original Message-----
From: <> On Behalf Of Leif Lindholm
Sent: Tuesday, December 15, 2020 9:17 AM
To: Kinney, Michael D <>
Cc:;;; Andrew Fish ( <>;
Laszlo Ersek <> ( <>; 'Sean Brogan' <>; '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

On Tue, Dec 15, 2020 at 16:53:09 +0000, Kinney, Michael D wrote:

The following bug has been fixed on edk2/master

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.

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:

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,


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,


Join to automatically receive all group messages.