On 03/02/2017 15:11, Ryan VanderMeulen 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/Committing_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?
As Greg said, the committer / pusher, via IRC and/or email.
* It makes tracking a pain - what happens if that patch ends up
needing uplift?
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.
What about when that patch causes conflicts with another patch needing
uplift?
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.
What if it causes a regression and a blocking bug needs to be filed?
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).
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.
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.
~ Gijs
Bugs are cheap. Please use them.
Thanks,
Ryan
_______________________________________________
firefox-dev mailing list
firefox-...@mozilla.org
https://mail.mozilla.org/listinfo/firefox-dev
_______________________________________________
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
