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:ler...@redhat.com] Sent: Friday, February 28, 2020 1:18 AM To: Feng, Bob C <bob.c.f...@intel.com>; devel@edk2.groups.io; Andrew Fish <af...@apple.com>; Leif Lindholm <l...@nuviainc.com>; Kinney, Michael D <michael.d.kin...@intel.com>; Gao, Liming <liming....@intel.com> Cc: Pierre Gondois <pierre.gond...@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 -=-=-=-=-=-=-=-=-=-=-=- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#55043): https://edk2.groups.io/g/devel/message/55043 Mute This Topic: https://groups.io/mt/71583896/21656 Group Owner: devel+ow...@edk2.groups.io Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
