On Fri, Feb 3, 2017 at 7:11 AM, Ryan VanderMeulen <rvandermeu...@mozilla.com > wrote:
> 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. > https://developer.mozilla.org/docs/Mozilla/Developer_guide/C > ommitting_Rules_and_Responsibilities > > 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: > * 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? > 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 https://github.com/glandium/pulsebot feature request waiting to be filed. > * 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? > Then you file a new bug "Changeset XXXXXX ...." As I argue at http://gregoryszorc.com/blog/2015/01/16/bugzilla-and-the- future-of-firefox-development/ 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. > > Bugs are cheap. Please use them. > 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. _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
