On 02/03/2017 09:29 AM, Gijs Kruitbosch wrote:
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.
For the immediate term, I must respectfully disagree. Sheriffs are the
people most involved with and concerned with the changeset management
procedures, so if the sheriffs (and Ryan "I'm not a sheriff!" VM) are
claiming that No Bug landings are being overused and causing issues, I'm
inclined to adjust current practices first and hold off on rethinking
our development process until the immediate pain is resolved. The fact
is that our *current* changeset management *is* very bug-centric. I
think gps and others have made a good argument for why another process
may be superior (and I personally do not regard our current process as
the pinnacle of efficiency), and I'm all for coming up with something
better. But I really don't want some long drawn-out halfway state where
the people who think the process should be A are doing it that way, the
people who think it should be B are changing piecemeal to get something
as close to B as is currently possible, and the people new to our
community are completely baffled and getting contradictory advice
depending on who they talk to.
Can we clarify with examples of good and bad usages of "No bug"? There
will always be a fuzzy middle (unless we go all-out and say every
landing must be associated with a bug). But I'm hearing some dispute
over specific scenarios, so I think it would be helpful to clarify. I am
not the one to decide such things, but my personal guess would be:
branch merges - No bug is fine. (And IIUC, you don't need to say "No
bug" for those because the hook accepts /merge/ or something like that.)
I personally wish that especially significant merges *did* have bugs to
make it a little easier to track problems back to a branch landing and
have a place for discussion of the reasons and risks.
Typo/whitespace - No bug is fine, but if it is associated with a recent
landing of some bug, then you should use that bug number anyway. Makes
uplifts cleaner.
Trivial bustage fixes - use the bug of the original commit.
Sync with upstream - use a bug! If it causes intermittents, or changes
in telemetry, or anything, then metadata beyond that stored in the
commit is very likely to be useful. Especially with anything that might
potentially be backported. I understand the argument that we can always
file a bug retroactively, but today our process is bug-centric and can
we please not change that without being fully intentional about it and
making sure that works for everyone (especially the sheriffs) first?
And after writing this, I went and read the developer guidelines link,
and it seems to agree with all of these.
_______________________________________________
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
