From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mga03.intel.com (mga03.intel.com [134.134.136.65]) by mx.groups.io with SMTP id smtpd.web12.7323.1582853697847714361 for ; Thu, 27 Feb 2020 17:34:57 -0800 Authentication-Results: mx.groups.io; dkim=missing; spf=pass (domain: intel.com, ip: 134.134.136.65, mailfrom: bob.c.feng@intel.com) X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from fmsmga001.fm.intel.com ([10.253.24.23]) by orsmga103.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 27 Feb 2020 17:34:57 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.70,493,1574150400"; d="scan'208";a="350809742" Received: from fmsmsx103.amr.corp.intel.com ([10.18.124.201]) by fmsmga001.fm.intel.com with ESMTP; 27 Feb 2020 17:34:56 -0800 Received: from shsmsx602.ccr.corp.intel.com (10.109.6.142) by FMSMSX103.amr.corp.intel.com (10.18.124.201) with Microsoft SMTP Server (TLS) id 14.3.439.0; Thu, 27 Feb 2020 17:34:56 -0800 Received: from shsmsx601.ccr.corp.intel.com (10.109.6.141) by SHSMSX602.ccr.corp.intel.com (10.109.6.142) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1713.5; Fri, 28 Feb 2020 09:34:53 +0800 Received: from shsmsx601.ccr.corp.intel.com ([10.109.6.141]) by SHSMSX601.ccr.corp.intel.com ([10.109.6.141]) with mapi id 15.01.1713.004; Fri, 28 Feb 2020 09:34:53 +0800 From: "Bob Feng" To: Laszlo Ersek , "devel@edk2.groups.io" , Andrew Fish , Leif Lindholm , "Kinney, Michael D" , "Gao, Liming" CC: Pierre Gondois Subject: Re: [edk2-devel] [Patch 1/1][edk2-stable202002]BaseTools: Fixed a regression issue in Makefile for incremental build Thread-Topic: [edk2-devel] [Patch 1/1][edk2-stable202002]BaseTools: Fixed a regression issue in Makefile for incremental build Thread-Index: AQHV7Wrj9VQ9lhL7IkClUa3Lv95Gw6gvGo5A//+oHACAAQEbwA== Date: Fri, 28 Feb 2020 01:34:53 +0000 Message-ID: <59ddbcc3435147068083346783d61247@intel.com> References: <20200227094705.25404-1-bob.c.feng@intel.com> <32761feabc3847c6847b3ff908ce9014@intel.com> In-Reply-To: Accept-Language: zh-CN, en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.239.127.36] MIME-Version: 1.0 Return-Path: bob.c.feng@intel.com Content-Language: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Laszlo, I agree BZ status should be update in time. You do a very good prac= tices about that. I need to learn from you. And thank you that you have don= e a lot on BZ maintenance for me and other assignees.=20 I think we need have a document to record these good practices on BZ mainte= nance so that people can clear to know what information should be published= on BZ in each development stage. Thanks, Bob -----Original Message----- From: Laszlo Ersek [mailto:lersek@redhat.com]=20 Sent: Friday, February 28, 2020 1:18 AM To: Feng, Bob C ; devel@edk2.groups.io; Andrew Fish <= afish@apple.com>; Leif Lindholm ; Kinney, Michael D ; Gao, Liming Cc: Pierre Gondois Subject: Re: [edk2-devel] [Patch 1/1][edk2-stable202002]BaseTools: Fixed a = regression issue in Makefile for incremental build On 02/27/20 16:53, Feng, Bob C wrote: > [Bob] I agree the BZ status should be update in time. I don't think BZ st= atus update is the reviewer's/maintainer's responsibility, the BZ owner sho= uld be responsible for it. Agreed. >=20 > NOTE: GitHub.com Pull Requests would not help *at all* in the face of suc= h sloppiness; even on GitHub.com, people have to at least *name* issue numb= ers in commit messages. >=20 > - TianoCore#2563 (which tracks the regression) identifies *neither* the B= Z for which the regression was introduced (2481), *nor* the faulty commit (= 818283de3f6d). You realize it's *completely useless* to file BZs with such = negligence, right? It has no more information than "stuff broke, we need to= fix it" -- but ain't that the general state of things, at all times? Are y= ou only trying to fill a BZ quota? > [Bob] I don't agree this comments.=20 > I added the bug reproduce steps in BZ description. I think it's enough wh= en I submit a new BZ. I'll append the root cause and solution ( would be j= ust patch review link) in its comments when I update the BZ status later.=20 Yes, the patch explains the issue well. If the link had been in the BZ, I w= ouldn't have complained (as much). > We found this critical bug in this afternoon (PRC time) and root cause an= d created patch very quickly. I don't think that I did not update the BZ in= time is process violation. It was not clear that you ever intended to add the link to the BZ. > I think the necessary information was provided when the patch send out. T= he bug description and reproduce steps are in BZ, root cause is in the patc= h commit message, the solution is the patch itself, test result is in the c= ommit message. Yes. There was no link from the BZ to the patch however. And it wasn't poss= ible to determine whether you were going to add the link later. I tend to a= dd the link immediately after posting, so I don't forget. My experience tel= l me that most patch submitters that don't add the link at once forget for = good. Yes, it was a generalization, sorry about that. One thing I do have to admit (because I brought up GitHub.com before) is th= at, on GitHub.com, if you submit a pull request, and at least one of the co= mmit messages references an Issue (like your commit message here references= TianoCore#2563), then the issue automatically gets an update. So in that regard GitHub.com does save some manual work. Laszlo