<html>
<head>
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<div class="moz-cite-prefix">On 03/02/2017 15:11, Ryan VanderMeulen
wrote:<br>
</div>
<blockquote
cite="mid:CAPebk9fJxZ3HGsawKXzs8JuDMi7biLENDizPJrv8nK+e7aK_sA@mail.gmail.com"
type="cite">
<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 moz-do-not-send="true"
href="https://developer.mozilla.org/docs/Mozilla/Developer_guide/Committing_Rules_and_Responsibilities">https://developer.mozilla.org/docs/Mozilla/Developer_guide/Committing_Rules_and_Responsibilities</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>
As Greg said, the committer / pusher, via IRC and/or email.<br>
<blockquote
cite="mid:CAPebk9fJxZ3HGsawKXzs8JuDMi7biLENDizPJrv8nK+e7aK_sA@mail.gmail.com"
type="cite">
<div dir="ltr">
<div>* It makes tracking a pain - what happens if that patch
ends up needing uplift?</div>
</div>
</blockquote>
Generally, the person committing it will know whether it needs
uplift, and would have filed a bug if it did - and would file one if
it does after the fact. We can already not rely on bugs being marked
fixed/verified on a trunk branch when searching bugzilla for uplift
requests (cf. "disable feature Y on beta" bugs) and so I don't see
how this is relevant.<br>
<blockquote
cite="mid:CAPebk9fJxZ3HGsawKXzs8JuDMi7biLENDizPJrv8nK+e7aK_sA@mail.gmail.com"
type="cite">
<div dir="ltr">
<div> What about when that patch causes conflicts with another
patch needing uplift?</div>
</div>
</blockquote>
That seems like it hardly ever happens in the example you gave
(vendored libraries and other wholesale "update this dir to match
external canonical version"), and if/when it does, the people who
would be likely to be involved in such changes (effectively changes
to vendored deps that aren't copied from the same canonical source!)
are also likely to be aware of what merged when.<br>
<blockquote
cite="mid:CAPebk9fJxZ3HGsawKXzs8JuDMi7biLENDizPJrv8nK+e7aK_sA@mail.gmail.com"
type="cite">
<div dir="ltr">
<div> What if it causes a regression and a blocking bug needs to
be filed?<br>
</div>
</div>
</blockquote>
Then you file a bug and needinfo the person who landed the commit
(which one would generally do anyway, besides just marking it
blocking the regressor).<br>
<br>
<br>
If there's an overwhelming majority of people who think using "no
bug" for landing 'sync m-c with repo X' commits is bad, we can make
a more explicit change in the rules here. But in terms of reducing
development friction, if we think bugs are necessary at this point,
I would prefer doing something like what Greg suggested, ie
auto-file bugs for commits that get pushed that don't have a bug
associated with them.<br>
<br>
<br>
More generally, I concur with Greg that we should pivot to having
the repos be our source of truth about what csets are present on
which branches. I've seen cases recently where e.g. we land a
feature, then there are regressions, and some of them are addressed
in followup bugs, and then eventually we back everything out of one
of the trains because we can't fix *all* the regressions in time. At
that point, the original feature bug's flags are updated ('disabled'
on the branch with backouts), but not those of the regression fix
deps, and so if *those* have regressions, people filing bugs make
incorrect assumptions about what versions are affected. Manually
tracking branch fix state in bugzilla alone is a losing battle.<br>
<br>
~ Gijs<br>
<br>
<blockquote
cite="mid:CAPebk9fJxZ3HGsawKXzs8JuDMi7biLENDizPJrv8nK+e7aK_sA@mail.gmail.com"
type="cite">
<div dir="ltr">
<div><br>
</div>
<div>Bugs are cheap. Please use them.<br>
<br>
</div>
<div>Thanks,<br>
</div>
<div>Ryan<br>
</div>
</div>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
firefox-dev mailing list
<a class="moz-txt-link-abbreviated" href="mailto:firefox-dev@mozilla.org">firefox-dev@mozilla.org</a>
<a class="moz-txt-link-freetext" href="https://mail.mozilla.org/listinfo/firefox-dev">https://mail.mozilla.org/listinfo/firefox-dev</a>
</pre>
</blockquote>
<p><br>
</p>
</body>
</html>