[RFC V2] Create supported branch from edk2-stable* tag (Required to address critical bug BZ3111)
Michael D Kinney
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.
Michael D Kinney
toggle quoted messageShow quoted text
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.
It is hard to predict how downstream platforms use a stable tag or a supported branch.The request here is to create a supported branch from edk2-stable202011 tagHere is my suggestion on the live period of the stable tag 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.
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.
In the general case where more than one critical bug may be fixed in aThe patch has been verified in master. CI test may not be necessary.
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.
Thank you. I will start work on a patch for review.3) Release requirements for supported branches.It is OK to create new stable tag per the request. The platform can use stable branch.
On 12/16/20 01:24, Kinney, Michael D wrote:
Hello,- 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:
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.