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

Laszlo Ersek

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.

Proposal: stable/<YYYY><MM>
Example: stable/202011

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.
- 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:;a=blob_plain;f=docs/devel/stable-process.rst;hb=HEAD

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.


Join to automatically receive all group messages.