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
    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

Reply via email to