From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-wr1-f67.google.com (mail-wr1-f67.google.com [209.85.221.67]) by mx.groups.io with SMTP id smtpd.web11.13441.1582894103747172238 for ; Fri, 28 Feb 2020 04:48:24 -0800 Authentication-Results: mx.groups.io; dkim=pass header.i=@nuviainc-com.20150623.gappssmtp.com header.s=20150623 header.b=TuQiGYgi; spf=pass (domain: nuviainc.com, ip: 209.85.221.67, mailfrom: leif@nuviainc.com) Received: by mail-wr1-f67.google.com with SMTP id j7so2739832wrp.13 for ; Fri, 28 Feb 2020 04:48:23 -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=LxeoIvIHMk3UBNa+bJbADJV03+rLGrR+8yagDHJfgeA=; b=TuQiGYginYsSh21VMyLLbWaFrOoOgEYYjSuo1iHlBwqvpDNk5QRRawIjuhdcSjLyNG CqOPjF3zhdaT6eZf0aZumBgwOP2FhD+Pr2oNIacCNelRuGcIHv6Yj8v5328QLnQ2Lgme 6IXkqlRun+4kJ0j9oQW8zKKfjCW+uXQ5Q5TyxRteRLj+EJn8D0wSP2k1rzBCk8sCMnbf zKTo3tlHYCVbtQz3mA95o/7q2etuafCY6Bjnb7bhT1yz884kxnoNvvbgGakNV1+sLBNi qKjvzeD7/Pa41LojKB+4mZW9g8+yJfRulJpN44TUKsdxsgIvb0p8JTBeXjRKUkZ/ZVbE 56kQ== 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=LxeoIvIHMk3UBNa+bJbADJV03+rLGrR+8yagDHJfgeA=; b=WWVAFKIEqtrHKVhzVjaZYknsX0k8Pg+Batm2n0K3F6y3cZXqk1P9a5I6WvCiydXQIB BEfYySu0jb5DDJz3I6m/aQLEgcQPlLDmJ+b9aneVOu6Jef/XkLG61h56XcVAsNTZTFc7 vPd7cxlGWiyy0PymipGpdu275CDgbcK0bn8TIzNRAuZAFo/K1WaLnWdfOHumwrSGTunq B3Ne492M/AFXPB6xlVmksK8Nt+4gvzaMqE3TPcSnPxep+dKo5wwAv2e+MRihFPoDJhXX 7kbkUnjZr2Hgu00blJKReS+Te3+GLM0pR4r9wGWttY7Q5thpAAlR/qMnbKHesBcVZcj8 jMdQ== X-Gm-Message-State: APjAAAVBtAGsP+o6SQU3L4OlDY5u6GvHESIpz9gG5dTtCOF2Mi0Y+FuN MIRKKn/Hejq2Jzc1z0UKeDzAbg== X-Google-Smtp-Source: APXvYqwAwovnZNuTyqs85y8sI6a0VC0mj74Xqv0BFXD1qnWQ5LXvT1UW3CotCLCuhTK0AjewqUKwnA== X-Received: by 2002:adf:f692:: with SMTP id v18mr4827547wrp.246.1582894102344; Fri, 28 Feb 2020 04:48:22 -0800 (PST) Return-Path: Received: from bivouac.eciton.net (bivouac.eciton.net. [2a00:1098:0:86:1000:23:0:2]) by smtp.gmail.com with ESMTPSA id d4sm1956609wmb.48.2020.02.28.04.48.21 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 28 Feb 2020 04:48:21 -0800 (PST) Date: Fri, 28 Feb 2020 12:48:20 +0000 From: "Leif Lindholm" To: "Gao, Liming" Cc: Laszlo Ersek , "devel@edk2.groups.io" , "Kinney, Michael D" , "afish@apple.com" , "Guptha, Soumya K" , Marvin =?iso-8859-1?Q?H=E4user?= , "Gao, Zhichao" , "'ard.biesheuvel@linaro.org'" , "Wu, Hao A" , vit9696 , "gaurav.jain@nxp.com" , "Ni, Ray" , "Feng, Bob C" , "maciej.rabeda@linux.intel.com" , "leo.duran@amd.com" Subject: Re: [edk2-devel] Patch List for 202002 stable tag Message-ID: <20200228124820.GE23627@bivouac.eciton.net> References: <21493dd751f34291a59874d55c34fd13@intel.com> <10a293f739eb428c9c022615eafb0398@intel.com> <734D49CCEBEEF84792F5B80ED585239D5C447005@SHSMSX104.ccr.corp.intel.com> <15F50A1858BD174A.18319@groups.io> <15F55D425BF8837D.15709@groups.io> <8adb33d816bf4f45abd6d831403e6d01@intel.com> <20200227162318.GC23627@bivouac.eciton.net> <51eae9d3-b891-2685-186b-023a82bdebcc@redhat.com> 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 On Fri, Feb 28, 2020 at 04:13:09 +0000, Gao, Liming wrote: > > > I agree it needs to catch the stable tag. If it affects only VS builds > > > then I am not going to insist on extending the hard freeze, but I > > > (technically on holiday today/tomorrow) don't have time to dig much > > > deeper into it. > > > > [Liming] This fix is to restore the original behavior before the commit 818283de3f6d > for !INCLUDE style in Makefile generation. It does update GNUmakefile and VS makefile > generation. Because it just restores original behavior, its quality risk is low. So, I suggest > to catch it in this stable tag on current release planning. If it is *just* a revert, then the risk is often low enough to not slip the date. But I think, as you say, this is something that restores original behaviour - but leaving the code different from the original. > > > However, I think the process is pretty clear that this *should* extend > > > the hard freeze. > > [Liming] I am not aware of the process to extend the hard freeze. But, you think more time is > required for the review and test on the critical bug fix. I am OK. > > > > I will note that from the trail (commitdate of 818283de3f6d until > > > BZ2563 was raised) it appears that detecting this bug itself, which > > > went in two days before the soft freeze, took 15 days. > > [Liming] Yes. It takes 15 days to expose this issue. > > > I agree with Liming's analysis on the patches (i.e., what goes in and > > what gets postponed), and I agree with Leif that we should extend the > > hard freeze by at least a couple of days. > > [Liming] If you both agree to extend the hard freeze, I have no objection. > I request to extend few days instead of few weeks if no other critical issues are reported. > Then, the impact of the community can be reduced. > > > This is not unusual. Originally I thought that edk2 freeze and release > > dates were set in stone, but then Mike explained to me that that had > > never been the intent. And other open source projects do several > > pre-releases (rc0, rc1, .... pre-releases with "release critical" (rc) > > bug fixes), before a final release. For example, QEMU regularly plans > > rc0..rc2 or even rc3, and then *optionally* adds an rc4 if even rc3 > > receives significant bugfixes. The idea is that the final release / tag > > should be preceded by a silent / calm period, where we've waited a few > > days and become reasonably convinced that "OK, there's nothing else we > > should obviously fix right now". > > > > I wouldn't immediately suggest a full week extension, but maybe until > > March 4th (middle of next week)? > [Liming] March 4th is one good choice to reserve few days for the different time zone people. > If no more feedback, I will send announcement to delay this stable tag on Feb 28th (00:00:00 UTC-8). I am OK with March 4th. Thanks! / Leif