<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Fri, Feb 3, 2017 at 7:11 AM, Ryan VanderMeulen <span dir="ltr"><<a href="mailto:rvandermeulen@mozilla.com" target="_blank">rvandermeulen@mozilla.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div><div><div><div>A friendly reminder that per the MDN commit rules, the use of "No bug" in the commit message is to be used sparingly - in general for minor things like whitespace changes/comment fixes/etc where traceability isn't as important.<br><a href="https://developer.mozilla.org/docs/Mozilla/Developer_guide/Committing_Rules_and_Responsibilities" target="_blank">https://developer.mozilla.org/<wbr>docs/Mozilla/Developer_guide/C<wbr>ommitting_Rules_and_Responsibi<wbr>lities</a><br><br></div>I've come across uses of "No bug" commits recently where entire upstream imports of vendored libraries were done. This is bad for multiple reasons:<br></div>* If makes sheriffing difficult - if the patch is broken and needs backing out, where should the comment go? When it gets merged to mozilla-central, who gets notified?<br></div></div></div></blockquote><div><br></div><div>The commit author and/or who pushed the commit. We have email addresses in the commit message and the pushlog. We should use them. There is a <a href="https://github.com/glandium/pulsebot" target="_blank">https://github.com/glandium/<wbr>pulsebot</a> feature request waiting to be filed.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div><div></div>* It makes tracking a pain - what happens if that patch ends up needing uplift? What about when that patch causes conflicts with another patch needing uplift? What if it causes a regression and a blocking bug needs to be filed?<br></div></div></blockquote><div><br></div><div>Then you file a new bug "Changeset XXXXXX ...." As I argue at <a href="http://gregoryszorc.com/blog/2015/01/16/bugzilla-and-the-future-of-firefox-development/" target="_blank">http://gregoryszorc.com/blog/<wbr>2015/01/16/bugzilla-and-the-<wbr>future-of-firefox-development/</a> we've conflated bugs with changesets/landings and I don't think this is optimal. At the end of the day, the changeset/commit is the thing that matters because a bug doesn't directly change the behavior of Firefox. Instead, bugs are convenient anchor points for {discussion, tracking, review, etc} that just so happen to exist most of the time because 10+ years ago we tightly coupled our code review mechanism into Bugzilla, which requires the existence of a bug.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div></div><div><br></div><div>Bugs are cheap. Please use them.<br></div></div></blockquote><div><br></div><div>They are. But there is still a cost to them. While I agree that things like imports of upstream code are an abuse of "no bug," I feel strongly that we shouldn't institute avoidable process overhead, especially for things like trivial whitespace or comment changes. If we insist on having a bug for every changeset, then I insist we teach the review/landing process to create bugs automatically when a bugless changeset is seen so people aren't burdened with the overhead of doing that. We have most of the technical pieces in place to support this, including bug 1328351 annotating every file in the tree with a bug component.<br></div></div></div></div>