On Wed, Nov 28, 2018 at 1:34 PM James Graham <ja...@hoppipolla.co.uk> wrote:
> Can you share with us the long term vision for what the workflow is > going to look like here? I've recently seen a few cases where > experienced develoeprs who have either never contributed to gecko before > or contribute infrequently tried to get things set up for a patch to get > into review, and it seems like there was a lot of frustration caused by > accidental complexity that's mostly hidden from people who are already > up and running. Some of the issues encountered seemed to be: > We're still working through a longer-term vision that we'll share early next year, but I can answer some questions now. > * 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. My team has pretty much nothing to do with the gecko GitHub clone; we need to keep our focus on the "standard" workflow. > * 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. > * 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. 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. > I appreciate that moving to new tooling is a tricky process and that's > why there are rough edges at the moment. But it would be really useful > to be able to tell people that the issues they are facing are understood > to be pain points and are going to go away in the future :) > Agreed, stay tuned for more details in 2019Q1. :) Mark _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
