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
use
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
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.
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
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
