On 28/11/2018 20:15, Mark Côté wrote:
We're still working through a longer-term vision that we'll share early next year, but I can answer some questions now.

Thanks, this is helpful!

    * Have to make a choice early on about whether to learn a relatively
    unfamiliar (to the majority of developers) VCS (mercurial), use a
    slightly unorthodox git setup with slow initial clone (cinnabar), or
    the largely unsupported (?) GitHub clone.

This is a very difficult problem. I can't see this problem going away entirely without some sort of executive decision to require everyone use a particular VCS. That said, Mercurial should still be seen as the default VCS, especially as we get partial-clone support (https://bugzilla.mozilla.org/show_bug.cgi?id=1505555). Git-cinnabar should be treated as an "advanced" option. Perhaps docs could be clarified as to this.

I understand that mercurial is not going away :) Having said that it's a pretty hard sell to get someone to make an initial contribution if it involves learning a whole new VCS; that's a considerable investment of time on its own. I wonder if there's something we could do to help people here like run a taskcluster task on m-c to produce an artifact containing a cinnabar clone archived using git-bundle, and then set up the bootstrap.py script to give a choice between mercurial and git using cinnabar, and in the git case, do the initial clone by downloading a recent bundle and then fetching missing commits. There's probably a good reason that won't work, but I'm not sure what it is yet :)

My team has pretty much nothing to do with the gecko GitHub clone; we need to keep our focus on the "standard" workflow.

Sure, the problem is that it's an attractive nuisance for new contributors who find it and go "It's a GitHub repo! I know this" without realising it's largely unsupported.

    * Cloning the repository doesn't provide you with the right tooling to
    actually request review on a patch. You have to download something else
    and — particularly if you wrote the patch as a series of commits —
    there's a choice of tools at various levels of completeness. If you use
    something backed by arcanist this probably involves installing
    system-level dependencies that aren't handled by mach bootstrap.

Yes, this is an issue we'll be addressing. The first step is to stop using Arcanist in moz-phab; not only does it introduce other dependencies (PHP) but it is causing some performance issues in moz-phab as well. After that, we can see about installing it via mach bootstrap or such.

Sounds good. It would be great if we can get to a place where submitting/updating a review is just `mach review [commits]`, or similar.

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

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.
dev-platform mailing list

Reply via email to