toggle quoted messageShow 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.
From: firstname.lastname@example.org <email@example.com> On Behalf Of Leif Lindholm
Sent: Tuesday, December 15, 2020 9:17 AM
To: Kinney, Michael D <michael.d.kinney@...>
Cc: firstname.lastname@example.org; email@example.com; gaoliming@...; Andrew Fish (afish@...) <afish@...>;
Laszlo Ersek <lersek@...> (lersek@...) <lersek@...>; 'Sean Brogan' <sean.brogan@...>; 'Bret
Subject: Re: [edk2-rfc] [RFC] Create supported branch from edk2-stable* tag (Required to address critical bug BZ3111)
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:
Hello,For the bikeshedding part, if we're doing the branches, I support
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.
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.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.
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.