Theodore Tso (tytso@xxxxxxxxxx) wrote: > On Thu, Jan 12, 2012 at 4:53 PM, Mandeep Singh Baines <msb@xxxxxxxxxxxx>wrote: > > > > > Hi Greg, > > > > What is the conventional way of doing this? There is a lot of good > > data in the bug report which might be useful to reviewers. We > > couldn't find a de-facto way of referencing the downstream bug database > > so we just made up a new field. Sorry. We'll use the correct > > field name next time. > > > > There isn't a "correct field name", since it hasn't been standardized. I > can tell you as an the ext4 maintainer, I've put things like > > Addresses-Redhat-Bugzilla: <Bugzilla #> > > or > > Addresses-Debian-Bug: <debian-bug-number> > This seems like a good convention. Its also nice in that it scales to the case where the bug is reported by multiple distros. For future, we'll use: Addresses-ChromiumOS-Bug: http://crosbug.com/<Bug #> I included the URL because its small and folks might not know where our bug database is. Regards, Mandeep > etc. in commit messages. I usually put them before the signed-off-block, > i.e, like this: > > -------- > ext4: a simple commit > > This is the longer commit description, blah, blah, blah. > > Addresses-Redhat-Bugzilla: 12345 > > Signed-off-by: Eric Sandeen <....@redhat.com> > Signed-off-by: Theodore Ts'o <tytso@xxxxxxx> > ----------- > > There is some disagreement about whether it's useful to do this for > bugzilla entries which are not publically available (i.e., protected > Enterprise Linux bugzillas which have customer information and thus are > restricted access, or internal Company bug numbers). > > My personal take on this matter is that if an engineer from a particular > company has taken the time and effort to contribute a bug that fixes a bug > that they had seen internally, and they include an internal bug number, > it's presumably to make it easier to track when a particular commit fixing > a bug that they really care about has hit upstream, and it's in my interest > to keep the code contributions coming, and it's very little effort to > include an internal bug tracker reference, even if I don't have personal > access to said bug tracker; it's a nice thing I can do that doesn't cost > much, and may be useful to the original patch submitter. > > Others, including Greg K-H, think it's a horrible thing to do, and will > reject commits on that basis. > > So it all depends on which subsystem maintainer handles your bug..... at > the end, it's up to the maintainer. I've never had Linus complain to me > because the commits that I ask him to pull might include "Google-Bug-Id: > 12345" lines in the commit description. > > -- Ted > > > > > > > > > > So what is the correct field name? > > > > Regards, > > Mandeep > > > > > And shouldn't this go to the stable kernel releases as well? > > > > > > Third time's a charm? > > > > > > greg k-h > > -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
