On 12/16/20 01:24, 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.
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.
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
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.