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

["Laszlo Ersek" <lersek@redhat.com>]

On 12/16/20 01:24, Kinney, Michael D wrote:
> Hello,
> 
> The following bug has been fixed on edk2/master
> 
>     https://bugzilla.tianocore.org/show_bug.cgi?id=3111
>     https://github.com/tianocore/edk2/pull/1226
> 
> 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.
> 
>     https://github.com/tianocore/edk2/pull/1226/commits/893cfe2847b83da74f53858d6acaa15a348bad7c
>     https://github.com/tianocore/edk2/pull/1226/commits/16491ba6a6e9a91cedeeed45bc0fbdfde49f7968
> 
> 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:

https://git.qemu.org/?p=qemu.git;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.

Thanks
Laszlo