On 11/28/2018 01:20 PM, James Graham wrote:
On 28/11/2018 20:15, Mark Côté wrote: * It's not obvious to people
that patches can't go up for review
without
a preexisting bug, and won't actually be reviewed unless they
specify a
reviewer in the commit message (or go into Phabricator and add a
reviewer after the fact).
Part of this problem has always existed (knowing to pick a reviewer
and who); we've got plans to introduce suggested reviewers into the
flow in an even better way than it's done in Bugzilla. Timeline here
is a bit uncertain in part because there are some prerequisites.
Some system for auto-assigning reviewers where none are provided would
be a big win; even as a regular contributor I sometimes make changes
to parts of the tree where I have to guess a possible reviewer from
the VCS logs.
PSA for anyone unaware: on IRC, you can
/msg mrgiggles who has reviewed CodeGen.py?
and the bot will do that scan for you, looking at a bunch of past
revisions, grabbing out the reviewers and weighting them by recency,
then giving you the top few to choose from. Give the full path for
non-unique filenames. Please be aware that using this blindly will tend
to overload the most active reviewers. It also doesn't take authors into
account, only reviewers (the logs have the full name of authors and the
nicks of reviewers, with no mechanism implemented to correlate them.)
bugzilla also has suggested reviewers, and the poorly-named mqext
mercurial extension has a reviewers command that will do the above
process. Or look at an entire patch and take all of the modified files
into account.
We could also make moz-phab more helpful when it comes to bugs. And
of course there's still the controversial idea of not requiring bugs
for all patches that comes up now and again, but that's a (big)
policy question.
Yeah, I don't have a specific solution to suggest for the bugs thing,
but it's a real issue that people have. Maybe there's some compromise
where if you send commits for review without a bug the tooling can
offer to file one for you using the changed files to guess at the
product/component using the metadata in moz.buid files and the commit
message to set the bug summary/description.
(Not really relevant to anyone.)
I never quite got around to landing the code in the soon-to-be-obsolete
bzexport extension to do this, though I've been running with it in my
local version for several years. It's really handy to be able to make a
commit, then file a bug with no additional information and have it guess
at something sensible for the bug title, product, and component. (I also
never switched it to the moz.build metadata; it looks through the bugs
associated with past changes to the modified files instead.)
_______________________________________________
dev-platform mailing list
[email protected]
https://lists.mozilla.org/listinfo/dev-platform
