Re: [edk2-devel] [Patch 1/1][edk2-stable202002]BaseTools: Fixed a regression issue in Makefile for incremental build

["Bob Feng" <bob.c.feng@intel.com>]

Laszlo, I agree BZ status should be update in time. You do a very good practices about that. I need to learn from you. And thank you that you have done a lot on BZ maintenance for me and other assignees. 

I think we need have a document to record these good practices on BZ maintenance 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] 
Sent: Friday, February 28, 2020 1:18 AM
To: Feng, Bob C <bob.c.feng@intel.com>; devel@edk2.groups.io; Andrew Fish <afish@apple.com>; Leif Lindholm <leif@nuviainc.com>; Kinney, Michael D <michael.d.kinney@intel.com>; Gao, Liming <liming.gao@intel.com>
Cc: Pierre Gondois <pierre.gondois@arm.com>
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 status update is the reviewer's/maintainer's responsibility, the BZ owner should be responsible for it.

Agreed.

> 
> NOTE: GitHub.com Pull Requests would not help *at all* in the face of such sloppiness; even on GitHub.com, people have to at least *name* issue numbers in commit messages.
> 
> - TianoCore#2563 (which tracks the regression) identifies *neither* the BZ 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 you only trying to fill a BZ quota?
> [Bob] I don't agree this comments. 
> I added the bug reproduce steps in BZ description. I think it's enough when I submit a new BZ.  I'll append the root cause and solution ( would be just patch review link) in its comments when I update the BZ status later. 

Yes, the patch explains the issue well. If the link had been in the BZ, I wouldn't have complained (as much).

> We found this critical bug in this afternoon (PRC time) and root cause and 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. The bug description and reproduce steps are in BZ, root cause is in the patch commit message, the solution is the patch itself, test result is in the commit message.

Yes. There was no link from the BZ to the patch however. And it wasn't possible to determine whether you were going to add the link later. I tend to add the link immediately after posting, so I don't forget. My experience tell 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 that, on GitHub.com, if you submit a pull request, and at least one of the commit 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