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

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

[Michael D Kinney]

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.
  
Thank you,

Mike

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

[gaoliming]

Mike:

> -----邮件原件-----
> 发件人: Kinney, Michael D <michael.d.kinney@intel.com>
> 发送时间: 2020年12月16日 8:25
> 收件人: devel@edk2.groups.io; rfc@edk2.groups.io;
> gaoliming@byosoft.com.cn; Andrew Fish (afish@apple.com)
> <afish@apple.com>; Leif Lindholm <leif@nuviainc.com>; Laszlo Ersek
> <lersek@redhat.com> (lersek@redhat.com) <lersek@redhat.com>; 'Sean
> Brogan' <sean.brogan@microsoft.com>; 'Bret Barkelew'
> <Bret.Barkelew@microsoft.com>; Kinney, Michael D
> <michael.d.kinney@intel.com>
> 主题: [RFC V2] Create supported branch from edk2-stable* tag (Required to
> address critical bug BZ3111)
> 
> 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/893cfe2847b83da74f
> 53858d6acaa15a348bad7c
> 
> https://github.com/tianocore/edk2/pull/1226/commits/16491ba6a6e9a91ce
> deeed45bc0fbdfde49f7968
> 
[Liming] This one is for unit test. It is not critical fix. I don't think it is required.

> 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
Here is my suggestion on the live period of the stable tag branch. 
The stable tag branch will be created only when the critical issue is found in this stable tag. By default, no stable tag branch is created. 
Now, the quarterly stable tag will be created every three months. So, this branch will exist for at most three months. 
Once next stable tag is created, new stable tag will be used. Previous stable tag branch will not be maintained. 
That means only latest stable tag branch will be maintained if it is created. 

> 
> 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.
> 
The patch has been verified in master. CI test may not be necessary. 

> 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
> 
It is OK to create new stable tag per the request. The platform can use stable branch.

Besides, there are few new issues. I have cancelled the bug triage meeting. 

Thanks
Liming
> Please let me know if you have any feedback or comments on this proposal.
> The goal
> is to close on this topic this week.
> 
> Thank you,
> 
> Mike

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

[Michael D Kinney]

> -----Original Message-----
> From: gaoliming <gaoliming@byosoft.com.cn>
> Sent: Tuesday, December 15, 2020 5:19 PM
> To: Kinney, Michael D <michael.d.kinney@intel.com>; devel@edk2.groups.io; rfc@edk2.groups.io; 'Andrew Fish'
> <afish@apple.com>; 'Leif Lindholm' <leif@nuviainc.com>; lersek@redhat.com; 'Sean Brogan' <sean.brogan@microsoft.com>;
> 'Bret Barkelew' <Bret.Barkelew@microsoft.com>
> Subject: 回复: [RFC V2] Create supported branch from edk2-stable* tag (Required to address critical bug BZ3111)
> 
> Mike:
> 
> > -----邮件原件-----
> > 发件人: Kinney, Michael D <michael.d.kinney@intel.com>
> > 发送时间: 2020年12月16日 8:25
> > 收件人: devel@edk2.groups.io; rfc@edk2.groups.io;
> > gaoliming@byosoft.com.cn; Andrew Fish (afish@apple.com)
> > <afish@apple.com>; Leif Lindholm <leif@nuviainc.com>; Laszlo Ersek
> > <lersek@redhat.com> (lersek@redhat.com) <lersek@redhat.com>; 'Sean
> > Brogan' <sean.brogan@microsoft.com>; 'Bret Barkelew'
> > <Bret.Barkelew@microsoft.com>; Kinney, Michael D
> > <michael.d.kinney@intel.com>
> > 主题: [RFC V2] Create supported branch from edk2-stable* tag (Required to
> > address critical bug BZ3111)
> >
> > 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/893cfe2847b83da74f
> > 53858d6acaa15a348bad7c
> >
> > https://github.com/tianocore/edk2/pull/1226/commits/16491ba6a6e9a91ce
> > deeed45bc0fbdfde49f7968
> >
> [Liming] This one is for unit test. It is not critical fix. I don't think it is required.


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.

> 
> > 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
> Here is my suggestion on the live period of the stable tag branch.
> The stable tag branch will be created only when the critical issue is found in this stable tag. By default, no stable tag
> branch is created.
> Now, the quarterly stable tag will be created every three months. So, this branch will exist for at most three months.
> Once next stable tag is created, new stable tag will be used. Previous stable tag branch will not be maintained.
> That means only latest stable tag branch will be maintained if it is created.

It is hard to predict how downstream platforms use a stable tag or a supported 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.

> 
> >
> > 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.
> >
> The patch has been verified in master. CI test may not be necessary.

In the general case where more than one critical bug may be fixed in a 
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.

> 
> > 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
> >
> It is OK to create new stable tag per the request. The platform can use stable branch.

Thank you.  I will start work on a patch for review.

> 
> Besides, there are few new issues. I have cancelled the bug triage meeting.
> 
> Thanks
> Liming
> > Please let me know if you have any feedback or comments on this proposal.
> > The goal
> > is to close on this topic this week.
> >
> > Thank you,
> >
> > Mike
> 

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

[gaoliming]

Mike:

> -----邮件原件-----
> 发件人: Kinney, Michael D <michael.d.kinney@intel.com>
> 发送时间: 2020年12月16日 10:52
> 收件人: gaoliming <gaoliming@byosoft.com.cn>; devel@edk2.groups.io;
> rfc@edk2.groups.io; 'Andrew Fish' <afish@apple.com>; 'Leif Lindholm'
> <leif@nuviainc.com>; lersek@redhat.com; 'Sean Brogan'
> <sean.brogan@microsoft.com>; 'Bret Barkelew'
> <Bret.Barkelew@microsoft.com>; Kinney, Michael D
> <michael.d.kinney@intel.com>
> 主题: RE: [RFC V2] Create supported branch from edk2-stable* tag (Required
> to address critical bug BZ3111)
> 
> > -----Original Message-----
> > From: gaoliming <gaoliming@byosoft.com.cn>
> > Sent: Tuesday, December 15, 2020 5:19 PM
> > To: Kinney, Michael D <michael.d.kinney@intel.com>;
> devel@edk2.groups.io; rfc@edk2.groups.io; 'Andrew Fish'
> > <afish@apple.com>; 'Leif Lindholm' <leif@nuviainc.com>;
> lersek@redhat.com; 'Sean Brogan' <sean.brogan@microsoft.com>;
> > 'Bret Barkelew' <Bret.Barkelew@microsoft.com>
> > Subject: 回复: [RFC V2] Create supported branch from edk2-stable* tag
> (Required to address critical bug BZ3111)
> >
> > Mike:
> >
> > > -----邮件原件-----
> > > 发件人: Kinney, Michael D <michael.d.kinney@intel.com>
> > > 发送时间: 2020年12月16日 8:25
> > > 收件人: devel@edk2.groups.io; rfc@edk2.groups.io;
> > > gaoliming@byosoft.com.cn; Andrew Fish (afish@apple.com)
> > > <afish@apple.com>; Leif Lindholm <leif@nuviainc.com>; Laszlo Ersek
> > > <lersek@redhat.com> (lersek@redhat.com) <lersek@redhat.com>; 'Sean
> > > Brogan' <sean.brogan@microsoft.com>; 'Bret Barkelew'
> > > <Bret.Barkelew@microsoft.com>; Kinney, Michael D
> > > <michael.d.kinney@intel.com>
> > > 主题: [RFC V2] Create supported branch from edk2-stable* tag (Required
> to
> > > address critical bug BZ3111)
> > >
> > > 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/893cfe2847b83da74f
> > > 53858d6acaa15a348bad7c
> > >
> > >
> https://github.com/tianocore/edk2/pull/1226/commits/16491ba6a6e9a91ce
> > > deeed45bc0fbdfde49f7968
> > >
> > [Liming] This one is for unit test. It is not critical fix. I don't think it is
> required.
> 
> 
> 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.
> 

This case is clear. One commit is for the bug fix, another is for the unit test. 
If the unit test is also important for this fix, it can be cherry-pick. I understand the critical bug fix is for the functionality only.

> >
> > > 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
> > Here is my suggestion on the live period of the stable tag branch.
> > The stable tag branch will be created only when the critical issue is found in
> this stable tag. By default, no stable tag
> > branch is created.
> > Now, the quarterly stable tag will be created every three months. So, this
> branch will exist for at most three months.
> > Once next stable tag is created, new stable tag will be used. Previous stable
> tag branch will not be maintained.
> > That means only latest stable tag branch will be maintained if it is created.
> 
> It is hard to predict how downstream platforms use a stable tag or a
> supported 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.
> 
If stable branch requires long term maintain, the stable branches will become more and more,
the branch maintain effort will be more and more. It may not be workable in open source edk2 community
unless there is the dedicated branch maintainers.

So, I suggest that downstream consumers maintain their downstream branch to include the hot fix. 
Edk2 stable branch is the reference for the downstream users.

Thanks
Liming
> 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.
> 
> >
> > >
> > > 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.
> > >
> > The patch has been verified in master. CI test may not be necessary.
> 
> In the general case where more than one critical bug may be fixed in a
> 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.
> 
> >
> > > 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
> > >
> > It is OK to create new stable tag per the request. The platform can use
> stable branch.
> 
> Thank you.  I will start work on a patch for review.
> 
> >
> > Besides, there are few new issues. I have cancelled the bug triage meeting.
> >
> > Thanks
> > Liming
> > > Please let me know if you have any feedback or comments on this
> proposal.
> > > The goal
> > > is to close on this topic this week.
> > >
> > > Thank you,
> > >
> > > Mike
> >

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:
> 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

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

[Bret Barkelew]

[-- Attachment #1: Type: text/plain, Size: 5994 bytes --]

“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.”

Seconded. We actually had to update our release process with this blurb recently:
https://microsoft.github.io/mu/How/release_process/#post-lts-and-archiving

- Bret

From: Laszlo Ersek<mailto:lersek@redhat.com>
Sent: Thursday, December 17, 2020 5:50 AM
To: Kinney, Michael D<mailto:michael.d.kinney@intel.com>; devel@edk2.groups.io<mailto:devel@edk2.groups.io>; rfc@edk2.groups.io<mailto:rfc@edk2.groups.io>; gaoliming@byosoft.com.cn<mailto:gaoliming@byosoft.com.cn>; Andrew Fish (afish@apple.com)<mailto:afish@apple.com>; Leif Lindholm<mailto:leif@nuviainc.com>; Sean Brogan<mailto:sean.brogan@microsoft.com>; Bret Barkelew<mailto:Bret.Barkelew@microsoft.com>
Subject: [EXTERNAL] Re: [RFC V2] Create supported branch from edk2-stable* tag (Required to address critical bug BZ3111)

On 12/16/20 01:24, Kinney, Michael D wrote:
> Hello,
>
> The following bug has been fixed on edk2/master
>
>     https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbugzilla.tianocore.org%2Fshow_bug.cgi%3Fid%3D3111&amp;data=04%7C01%7Cbret.barkelew%40microsoft.com%7C092cd97468a645f68e4308d8a292a636%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637438098026646126%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=wE%2B9eA3XrRxS58KUk6DbFZmvX9nvmWopzGoVRN5713k%3D&amp;reserved=0
>     https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Ftianocore%2Fedk2%2Fpull%2F1226&amp;data=04%7C01%7Cbret.barkelew%40microsoft.com%7C092cd97468a645f68e4308d8a292a636%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637438098026646126%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=MnXglF%2FvtUDAouXJvBUIRFq7TuPL2dKXohXwcEuY3zc%3D&amp;reserved=0
>
> 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://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Ftianocore%2Fedk2%2Fpull%2F1226%2Fcommits%2F893cfe2847b83da74f53858d6acaa15a348bad7c&amp;data=04%7C01%7Cbret.barkelew%40microsoft.com%7C092cd97468a645f68e4308d8a292a636%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637438098026646126%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=h19eR7KFYlerrva%2FVGMDb7DMVIUihINgAlOh96Hb2xI%3D&amp;reserved=0
>     https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Ftianocore%2Fedk2%2Fpull%2F1226%2Fcommits%2F16491ba6a6e9a91cedeeed45bc0fbdfde49f7968&amp;data=04%7C01%7Cbret.barkelew%40microsoft.com%7C092cd97468a645f68e4308d8a292a636%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637438098026656126%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=8nCkmGD5jRyfrsMID0ESAcUb8plWrRkFafvhPiS2Zo8%3D&amp;reserved=0
>
> 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://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgit.qemu.org%2F%3Fp%3Dqemu.git%3Ba%3Dblob_plain%3Bf%3Ddocs%2Fdevel%2Fstable-process.rst%3Bhb%3DHEAD&amp;data=04%7C01%7Cbret.barkelew%40microsoft.com%7C092cd97468a645f68e4308d8a292a636%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637438098026656126%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=bOmSbEHuU%2BqLr3mdmhP%2Foq%2BR7yy%2BVNUWbG367yhFwQE%3D&amp;reserved=0

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


[-- Attachment #2: Type: text/html, Size: 11373 bytes --]

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

[Michael D Kinney]

I agree that the default policy is to only support a branch until the next
stable tag.  My comments were only to address the potential for a request
after that defined support timeline.  If a portion of the community wants
to do the work required to support past that point, then I doubt we would
reject the idea.

I will only document the default policy.  Anything past that would have
to be raised as a new request.

Mike

> -----Original Message-----
> From: rfc@edk2.groups.io <rfc@edk2.groups.io> On Behalf Of Bret Barkelew via groups.io
> Sent: Thursday, December 17, 2020 10:46 AM
> To: Laszlo Ersek <lersek@redhat.com>; Kinney, Michael D <michael.d.kinney@intel.com>; devel@edk2.groups.io;
> rfc@edk2.groups.io; gaoliming@byosoft.com.cn; Andrew Fish (afish@apple.com) <afish@apple.com>; Leif Lindholm
> <leif@nuviainc.com>; Sean Brogan <sean.brogan@microsoft.com>
> Subject: Re: [edk2-rfc] [EXTERNAL] Re: [RFC V2] Create supported branch from edk2-stable* tag (Required to address
> critical bug BZ3111)
> 
> “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.”
> 
> Seconded. We actually had to update our release process with this blurb recently:
> https://microsoft.github.io/mu/How/release_process/#post-lts-and-archiving
> 
> - Bret
> 
> From: Laszlo Ersek<mailto:lersek@redhat.com>
> Sent: Thursday, December 17, 2020 5:50 AM
> To: Kinney, Michael D<mailto:michael.d.kinney@intel.com>; devel@edk2.groups.io<mailto:devel@edk2.groups.io>;
> rfc@edk2.groups.io<mailto:rfc@edk2.groups.io>; gaoliming@byosoft.com.cn<mailto:gaoliming@byosoft.com.cn>; Andrew Fish
> (afish@apple.com)<mailto:afish@apple.com>; Leif Lindholm<mailto:leif@nuviainc.com>; Sean
> Brogan<mailto:sean.brogan@microsoft.com>; Bret Barkelew<mailto:Bret.Barkelew@microsoft.com>
> Subject: [EXTERNAL] Re: [RFC V2] Create supported branch from edk2-stable* tag (Required to address critical bug BZ3111)
> 
> On 12/16/20 01:24, Kinney, Michael D wrote:
> > Hello,
> >
> > The following bug has been fixed on edk2/master
> >
> >
> https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbugzilla.tianocore.org%2Fshow_bug.cgi%3Fid%3D3111&amp;da
> ta=04%7C01%7Cbret.barkelew%40microsoft.com%7C092cd97468a645f68e4308d8a292a636%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7
> C637438098026646126%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;
> sdata=wE%2B9eA3XrRxS58KUk6DbFZmvX9nvmWopzGoVRN5713k%3D&amp;reserved=0
> >
> https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Ftianocore%2Fedk2%2Fpull%2F1226&amp;data=04%
> 7C01%7Cbret.barkelew%40microsoft.com%7C092cd97468a645f68e4308d8a292a636%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C63743
> 8098026646126%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=
> MnXglF%2FvtUDAouXJvBUIRFq7TuPL2dKXohXwcEuY3zc%3D&amp;reserved=0
> >
> > 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://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Ftianocore%2Fedk2%2Fpull%2F1226%2Fcommits%2F
> 893cfe2847b83da74f53858d6acaa15a348bad7c&amp;data=04%7C01%7Cbret.barkelew%40microsoft.com%7C092cd97468a645f68e4308d8a292a6
> 36%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637438098026646126%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2l
> uMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=h19eR7KFYlerrva%2FVGMDb7DMVIUihINgAlOh96Hb2xI%3D&amp;reserved=0
> >
> https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Ftianocore%2Fedk2%2Fpull%2F1226%2Fcommits%2F
> 16491ba6a6e9a91cedeeed45bc0fbdfde49f7968&amp;data=04%7C01%7Cbret.barkelew%40microsoft.com%7C092cd97468a645f68e4308d8a292a6
> 36%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637438098026656126%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2l
> uMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=8nCkmGD5jRyfrsMID0ESAcUb8plWrRkFafvhPiS2Zo8%3D&amp;reserved=0
> >
> > 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://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgit.qemu.org%2F%3Fp%3Dqemu.git%3Ba%3Dblob_plain%3Bf%3Ddo
> cs%2Fdevel%2Fstable-
> process.rst%3Bhb%3DHEAD&amp;data=04%7C01%7Cbret.barkelew%40microsoft.com%7C092cd97468a645f68e4308d8a292a636%7C72f988bf86f1
> 41af91ab2d7cd011db47%7C1%7C0%7C637438098026656126%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1h
> aWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=bOmSbEHuU%2BqLr3mdmhP%2Foq%2BR7yy%2BVNUWbG367yhFwQE%3D&amp;reserved=0
> 
> 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
> 
> 
> 
> 
>