From mboxrd@z Thu Jan 1 00:00:00 1970 Authentication-Results: mx.groups.io; dkim=missing; spf=pass (domain: redhat.com, ip: 209.132.183.28, mailfrom: lersek@redhat.com) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by groups.io with SMTP; Wed, 22 May 2019 06:05:20 -0700 Received: from smtp.corp.redhat.com (int-mx08.intmail.prod.int.phx2.redhat.com [10.5.11.23]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id E19E430198AA; Wed, 22 May 2019 13:05:01 +0000 (UTC) Received: from lacos-laptop-7.usersys.redhat.com (ovpn-120-230.rdu2.redhat.com [10.10.120.230]) by smtp.corp.redhat.com (Postfix) with ESMTP id 8E78E5799; Wed, 22 May 2019 13:04:57 +0000 (UTC) Subject: Re: [edk2-devel] [edk2] Soft Feature Freeze starts today for edk2-stable201905 To: devel@edk2.groups.io, liming.gao@intel.com Cc: "Kinney, Michael D" , "Cetola, Stephano" , Andrew Fish , Leif Lindholm References: <4A89E2EF3DFEDB4C8BFDE51014F606A14E44C967@SHSMSX104.ccr.corp.intel.com> <4A89E2EF3DFEDB4C8BFDE51014F606A14E44FA00@SHSMSX104.ccr.corp.intel.com> From: "Laszlo Ersek" Message-ID: <2dc9afe8-3f0f-fe87-cb8f-13aa18f9426b@redhat.com> Date: Wed, 22 May 2019 15:04:56 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: <4A89E2EF3DFEDB4C8BFDE51014F606A14E44FA00@SHSMSX104.ccr.corp.intel.com> X-Scanned-By: MIMEDefang 2.84 on 10.5.11.23 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.47]); Wed, 22 May 2019 13:05:14 +0000 (UTC) Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit On 05/22/19 14:09, Liming Gao wrote: > Here, I don't want to argue whether they are feature or bug. I just > want to share my thinking, and collect feedback, then work out the > clear rule so that all developers can follow. Good question. Assume we push a series that adds a feature, but then we realize it was not complete. Do we consider the rest of the work feature enablement, or bugfix for an earlier (already existing) feature? Maybe it helps if we try to determine the scope of the feature precisely, up-front, in the BZ. If a patch falls under that scope (and under nothing else, e.g. it is not a standalone fix for another bug in its own right), then we could consider it "feature addition / enablement". In that regard, the ShellPkg & EmulatorPkg patches would be feature enablement, not bug fixes. But I'm worried that this approach would only push the problem to a different location, namely, to determining the scope as precisely as possible in the TianoCore BZ. Sometimes we don't know that a module or package is affected in the scope, until we try something in practice. Laszlo