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

["Michael D Kinney" <michael.d.kinney@intel.com>]

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