From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-wr1-f41.google.com (mail-wr1-f41.google.com [209.85.221.41]) by mx.groups.io with SMTP id smtpd.web12.1132.1608061186065981163 for ; Tue, 15 Dec 2020 11:39:46 -0800 Authentication-Results: mx.groups.io; dkim=pass header.i=@nuviainc-com.20150623.gappssmtp.com header.s=20150623 header.b=Uo8Mcrrk; spf=pass (domain: nuviainc.com, ip: 209.85.221.41, mailfrom: leif@nuviainc.com) Received: by mail-wr1-f41.google.com with SMTP id 91so21014211wrj.7 for ; Tue, 15 Dec 2020 11:39:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nuviainc-com.20150623.gappssmtp.com; s=20150623; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=M0ztw57kRDYwX30p9k2M/1zpC09t8McgyLhd9Pq5cB0=; b=Uo8McrrkmjvYbGgN06XgRStRM1bTdrB1+BueGSUTEc/0kAFbHnv8ZMUV5CEBxC39H5 QNtCHiK+JLyuKaSjNtBmJu5ZPeL/8PVf8gnuDZXgCKVZPg+d7TogUVOuznnX7Mu91VOz NRWsobRZbbJKOyP8n9wMcfyFS3cAKz6M11YnDyz2k8aVLZq798vgH/+zQwlz4lVWgUQM endR20MHxAx5mQM9aRJoAHQCgYIYskLdpcRkUB8diKtKQaL/LXMmUGuCDAUf2a1Q4DRj Ct7fyFrO7Ey88B0Cb4F79OMrjghn+PMbIsgFe25OBtN7gSi3xZNEEWNW8Axx9TZb4mSx jmnQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=M0ztw57kRDYwX30p9k2M/1zpC09t8McgyLhd9Pq5cB0=; b=dPk/h1ftlJvck/LnigcbqSvLjisWPDpxJ7ekdfbfGwS9uRG+5V5xwsD5huAY+VNlZW jyJxlX5kau9/PhGVuJ+fTeUus9dqLu9Jmwib24xu0Rch1u/gBeov383p/cnsSmfDfArr yjbVqZmBC3vEq0XafY+68mkYFJY6YBdlI5jnXkV471A94UhL+nWCeohNKq0To8g90JlZ 9VZN2QMNJJCNciKuQlC0M9AroKg9BEE/awZxXy5dsezlrUV1LzMMPZPcIR8lIaREpgpf LlipBw7rfQPTKrVj3de1ObB8bikZ1mFgotut4xfLBRue6G6WKxPkDCAG+sKXkps3dsG/ QpdQ== X-Gm-Message-State: AOAM530W4XyaCHWD64KwMuHtqkkRDp6SWFbaDh9LUFvBW8zEFNJ9auWY L79DlLc9wvgMflJyRNzt4Hujsw== X-Google-Smtp-Source: ABdhPJwraFGUqyxLkqihq0LdMmjzQIAMQrR5XGdeY6IyZWhS0+8LVjb1fihFu+g1/Q8QNYYma6U2pw== X-Received: by 2002:adf:e8cd:: with SMTP id k13mr35912578wrn.193.1608061184590; Tue, 15 Dec 2020 11:39:44 -0800 (PST) Return-Path: Received: from vanye (cpc1-cmbg19-2-0-cust915.5-4.cable.virginm.net. [82.27.183.148]) by smtp.gmail.com with ESMTPSA id a12sm13284701wrh.71.2020.12.15.11.39.43 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 15 Dec 2020 11:39:44 -0800 (PST) Date: Tue, 15 Dec 2020 19:39:42 +0000 From: "Leif Lindholm" To: Bret Barkelew Cc: "Kinney, Michael D" , "rfc@edk2.groups.io" , "devel@edk2.groups.io" , "gaoliming@byosoft.com.cn" , "Andrew Fish (afish@apple.com)" , "Laszlo Ersek (lersek@redhat.com)" , Sean Brogan Subject: Re: [edk2-rfc] [RFC] Create supported branch from edk2-stable* tag (Required to address critical bug BZ3111) Message-ID: <20201215193942.GI1664@vanye> References: <20201215171648.GZ1664@vanye> MIME-Version: 1.0 In-Reply-To: User-Agent: Mutt/1.10.1 (2018-07-13) Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Makes sense. Let's go with the branch. Mike: yes, that was what I was suggesting wrt cherry-picking and pushing. Best Regards, Leif On Tue, Dec 15, 2020 at 19:06:21 +0000, Bret Barkelew wrote: > FWIW, we tried both branches and tags in Mu, and have gotten more > mileage out of branches. We will still do tags periodically (to > establish a point at which all the sub repos were put through a full > validation run), but our platform consumers have shown a preference > for just living on the stabilized branch. > > - Bret > > From: Kinney, Michael D > Sent: Tuesday, December 15, 2020 10:57 AM > To: rfc@edk2.groups.io; leif@nuviainc.com; Kinney, Michael D > Cc: devel@edk2.groups.io; gaoliming@byosoft.com.cn; Andrew Fish (afish@apple.com); Laszlo Ersek (lersek@redhat.com); Sean Brogan; Bret Barkelew > Subject: [EXTERNAL] RE: [edk2-rfc] [RFC] Create supported branch from edk2-stable* tag (Required to address critical bug BZ3111) > > Hi Leif, > > I think you are suggesting that a local branch could be created from edk2-stable202011 and the > 2 commits cherry-picked onto that local branch and then create a tag on that local branch and > only push the new tag to edk2 repo (e.g. edk2-stable202011.01). Correct? > > I think with this approach, we would wait for the community to request a new stable dot tag > (e.g. edk2-stable202011.01) with a specific set of commits. > > Another advantage of branch vs tag is that platforms that want to always use an edk2-stable* > tag with all the known critical bug fixes can pull the branch to get the latest fixes. Or select > a tag on the branch or a specific sha on the branch based on their platform requirements. If > a platform has to wait for a new stable dot tag then the platform can not test with those critical > fixes directly from the edk2 repo. They would have to create their own downstream. > > I think between the CI use case and this downstream platform use case, a branch has more > advantages than a tag. > > I am fine with removing the redundant use of 'stable' and 'edk2' in the branch naming proposal. > > Proposal: stable/* > Example: stable/202011 > > Thanks, > > Mike > > > -----Original Message----- > > From: rfc@edk2.groups.io On Behalf Of Leif Lindholm > > Sent: Tuesday, December 15, 2020 9:17 AM > > To: Kinney, Michael D > > Cc: devel@edk2.groups.io; rfc@edk2.groups.io; gaoliming@byosoft.com.cn; Andrew Fish (afish@apple.com) ; > > Laszlo Ersek (lersek@redhat.com) ; 'Sean Brogan' ; 'Bret > > Barkelew' > > Subject: Re: [edk2-rfc] [RFC] Create supported branch from edk2-stable* tag (Required to address critical bug BZ3111) > > > > Hi Mike, > > > > This looks fine to me. > > I will add a potential tweak that I won't strongly advocate for, but > > think should be considered: > > We don't technically need a branch for this; a tag could be pushed > > directly. > > > > On Tue, Dec 15, 2020 at 16:53:09 +0000, 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&data=04%7C01%7CBret.Barkelew%40microsoft.com%7C36133f4be9b24fbec5ca08d8a12b4024%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637436554422046735%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=EZCqLKBAXKgq8J40GFynYtqYIyhUpU7MIlT7wT4Cs9w%3D&reserved=0 > > > https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Ftianocore%2Fedk2%2Fpull%2F1226&data=04%7C01%7CBret.Barkelew%40microsoft.com%7C36133f4be9b24fbec5ca08d8a12b4024%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637436554422056729%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=pQG7sjlHRxwh5mugH3vNKoZt88b%2BD7W4YHspsdb%2BQZ8%3D&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&data=04%7C01%7CBret.Barkelew%40microsoft.com%7C36133f4be9b24fbec5ca08d8a12b4024%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637436554422056729%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=RiNVhyT3fmoVRtLP0fJqbuP1Ow26tDM31J1O6%2B01wMs%3D&reserved=0 > > > https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Ftianocore%2Fedk2%2Fpull%2F1226%2Fcommits%2F16491ba6a6e9a91cedeeed45bc0fbdfde49f7968&data=04%7C01%7CBret.Barkelew%40microsoft.com%7C36133f4be9b24fbec5ca08d8a12b4024%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637436554422056729%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=DpZO7U2yoqD%2BK%2F6OxIZoI%2FbIDMbtRr7UBMCBl9PxGkQ%3D&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/edk2-stable* > > > Example: stable/edk2-stable202011 > > > > For the bikeshedding part, if we're doing the branches, I support > > using the stable/ prefix, but I also think this obviates the need to > > include the word stable in the portion after /. > > Since branches unlike tags don't have global namespace, I also think > > there is no need for the edk2 portion of the name. > > So an example branch name could be: > > 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. > > > > This would of course mandate the use of 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. > > > Example : edk2-stable201111.01 > > > > Sounds good to me. > > > > Best Regards, > > > > Leif > > > > > 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 > > > > > > > > >