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; Fri, 16 Aug 2019 09:16:29 -0700 Received: from smtp.corp.redhat.com (int-mx03.intmail.prod.int.phx2.redhat.com [10.5.11.13]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id EB2BD693D6; Fri, 16 Aug 2019 16:16:28 +0000 (UTC) Received: from lacos-laptop-7.usersys.redhat.com (ovpn-116-63.ams2.redhat.com [10.36.116.63]) by smtp.corp.redhat.com (Postfix) with ESMTP id 30713187A7; Fri, 16 Aug 2019 16:16:25 +0000 (UTC) Subject: Re: [edk2-devel] [PATCH] UefiCpuPkg: Adding a new TSC library by using CPUID(0x15) TSC leaf To: "Gao, Liming" , "Kuo, Donald" , "Dong, Eric" , "devel@edk2.groups.io" Cc: "Ni, Ray" , "Zeng, Star" , "Chan, Amy" , "Chaganty, Rangasai V" , "Lai, Luke" , "Li, Kevin Y" , "leif.lindholm@linaro.org" , "afish@apple.com" , "Kinney, Michael D" References: <20190813105312.14836-1-donald.kuo@intel.com> <4A89E2EF3DFEDB4C8BFDE51014F606A14E4D15C2@SHSMSX104.ccr.corp.intel.com> From: "Laszlo Ersek" Message-ID: <305e8729-d681-6eef-fcd6-023bb53755a9@redhat.com> Date: Fri, 16 Aug 2019 18:16:25 +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: <4A89E2EF3DFEDB4C8BFDE51014F606A14E4D15C2@SHSMSX104.ccr.corp.intel.com> X-Scanned-By: MIMEDefang 2.79 on 10.5.11.13 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.25]); Fri, 16 Aug 2019 16:16:29 +0000 (UTC) Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit On 08/15/19 06:02, Gao, Liming wrote: > Donald: This change is a new feature. Now, it is not in edk2 feature > planning list. If you want to catch it into 201908 stable tag, please > get approve from Stewards first. I have cc this mail to all Stewards. - I don't mind adding a new feature, as long as it gets properly reviewed by package owners before we enter the soft feature freeze. - Looking at the BZ , a bit more documentation would be nice. - On the negative side, I'm very much *not* a fan of adding features to the open source edk2 tree without actually *consuming* the feature in an open source tree. Are the new library instances going to be put to use in edk2-platforms, perhaps? We discussed this topic earlier on some of the stewards' calls. On one hand, it's not uncommon to see library instances from Intel enter core edk2 packages without any dependent platform code, or even a detailed problem statement / purpose description (see e.g. commit 5c9bb86f171c and its surrounding commits). On the other hand, attempts in the past, to add libraries with well demonstrated and direct in-tree use cases, to edk2 core, have been rejected, from other submitters. (Here's one example: .) I'm not prying at proprietary platform information, but a new library added to edk2 core *should* be well-justified. The commit message on this patch is empty. It only references . And if I open the BZ, this is all I get: Need a new TSC library to check the CPUID leaf (EAX=0x15) for TSC. For new platform (start from SKL) can use CPUID and retire/remove the current override from AcpiTimerLib. Does this read like an actual feature request? (TimerLib is an MdePkg library class, so not exactly "niche".) Plus, the BZ isn't even marked as a feature request, to begin with (the Product field is wrong, it says "EDK2", which is for bugs, not features). Also, the patch is on the list, and the status is still CONFIRMED, and not IN_PROGRESS. Why are we making a joke of bug tracking? The purpose of a public bugzilla instance on the web is not just more red tape, not just to have one more administrative tool that we can abuse, ignore, and write off with make-believe actions. It's not like another issue tracker system (JIRA, Launchpad, GitHub, GitLab, you name it) would properly work with this level of neglect, either. In summary: I don't mind the feature, but the documentation around it should be *much* better. Thanks Laszlo