> Does `mach try` still require `git cinnabar` when using a `git` checkout
> of m-c, or does it work with `moz-git-tools` now too?
>

On Fri, Sep 15, 2017 at 4:51 PM, Nicholas Nethercote <n.net...@gmail.com

> wrote:

> Are there docs on how to use `./mach try`? `./mach help try` doesn't give
> much detail.
>

>
> Also, will https://mozilla-releng.net/trychooser/ still work? I'm
> generally more of a command line person than a GUI person, but this is one
> case where I find the GUI approach far more usable.
>

On 9/15/17 6:30 PM, Gregory Szorc wrote:
> we'd like to require the use of `mach try` for Try
> submissions.

On 9/15/17 6:58 PM, Boris Zbarsky wrote:
> On 9/15/17 6:30 PM, Gregory Szorc wrote:
>> we'd like to require the use of `mach try` for Try
>> submissions.
>
> So just to be clear, instead of being able to "hg push -f try" will
> one now need to do "./mach try syntax ....." and put in the actual
> syntax string on every single try push?
>
> The reason I ask is that a very common use case for me is having a
> single try syntax that I want to apply to multiple changesets (e.g.
> bisecting things on try, or doing A/B comparisons on some tests
> with/without some patches, etc).  Having a trysyntax changeset or ten
> in my mq works pretty well for this.  I can give them names that
> indicate what sort of try push they do, so if I want to do a "linux64,
> tests, no talos" changeset I don't have to go around digging for the
> try syntax for it: I already have something that has a name indicating
> that, and qpushing it is pretty easy with the name-substring matching
> qpush does.
>
> There are obviously ways mach try could support this, e.g. by being
> able to easily define aliases for particular ways of pushing to try or
> whatnot.  But it doesn't have an obvious way of doing that right now.

On 9/15/17 10:08 PM, Steve Fink wrote:
> I've never used it, but it already has pretty much exactly this. Look at
> --save, --preset, and --list-presets under ./mach help try syntax

On Fri, Sep 15, 2017 at 7:54 PM Bobby Holley <bobby...@gmail.com> wrote:

> FWIW, I've found |./mach try fuzzy| to be very intuitive and kind of the
> best of both worlds for command-line vs GUI. I don't know what the
> non-fuzzy version does, but perhaps fuzzy should be the default.
>

> On Fri, Sep 15, 2017 at 4:51 PM, Nicholas Nethercote <
> n.net...@gmail.com
> > wrote:
>
> > Are there docs on how to use `./mach try`? `./mach help try` doesn't give
> > much detail.
> >

> > Also, will https://mozilla-releng.net/trychooser/ still work? I'm
> > generally
> > more of a command line person than a GUI person, but this is one case
> where
> > I find the GUI approach far more usable.
> >

On Fri, Sep 15, 2017 at 7:44 PM, Eric Rescorla <e...@rtfm.com> wrote:

> What happens if you are using git?
>

On Fri, Sep 15, 2017 at 8:33 PM, Gregory Szorc <g...@mozilla.com> wrote:

> On Fri, Sep 15, 2017 at 7:44 PM, Eric Rescorla <e...@rtfm.com> wrote:
>
>> What happens if you are using git?
>>
>
> git-cinnabar is already supported.
>

> Vanilla git is TBD. I see bug 1400470 was just filed for that.
>

On Fri, Sep 15, 2017 at 8:37 PM, Eric Rescorla <e...@rtfm.com> wrote:

>
>
> On Fri, Sep 15, 2017 at 8:33 PM, Gregory Szorc <g...@mozilla.com> wrote:
>
>> On Fri, Sep 15, 2017 at 7:44 PM, Eric Rescorla <e...@rtfm.com> wrote:
>>
>>> What happens if you are using git?
>>>
>>
>> git-cinnabar is already supported.
>>
>
> Supported how? Do I have to have special remote names? Special refs? Or
> does it mess with my git config?
>

>
>
>
>> Vanilla git is TBD. I see bug 1400470 was just filed for that.
>>
>
> Having this fixed seems like a blocker.
>

On Fri, Sep 15, 2017 at 9:25 PM, Gregory Szorc <g...@mozilla.com> wrote:

> On Fri, Sep 15, 2017 at 8:37 PM, Eric Rescorla <e...@rtfm.com> wrote:
>
>>
>>
>> On Fri, Sep 15, 2017 at 8:33 PM, Gregory Szorc <g...@mozilla.com> wrote:
>>
>>> On Fri, Sep 15, 2017 at 7:44 PM, Eric Rescorla <e...@rtfm.com> wrote:
>>>
>>>> What happens if you are using git?
>>>>
>>>
>>> git-cinnabar is already supported.
>>>
>>
>> Supported how? Do I have to have special remote names? Special refs? Or
>> does it mess with my git config?
>>
>
> It "just works." Git doesn't require remotes or tracking refs to do pushes
> and the git-cinnabar `mach try` integration doesn't make meaningful (read:
> outside of reflog) persisted changes to your repo state as part of doing
> its job.
>
>
>>
>>
>>
>>> Vanilla git is TBD. I see bug 1400470 was just filed for that.
>>>
>>
>> Having this fixed seems like a blocker.
>>
>
> Maybe. The policy is to support Git as a VCS tool for Firefox development.
> Previously, git-cinnabar - but not vanilla Git - has counted. e.g.
> git-mozreview and artifact builds require cinnabar. I would strongly prefer
> to maintain the "support Git == git-cinnabar" interpretation because
> otherwise we're looking at supporting N+1 tools (where the +1 for vanilla
> Git is *substantially* more effort than the existing Mercurial +
> git-cinnabar).
>

> I'd prefer to take a data-driven approach to answering the question of "do
> we need to support vanilla Git." I wish I had local developer metrics or
> results from a recent developer survey to feed into a decision. In lieu of
> that data, I'd encourage users of vanilla Git to make noise on bug 1400470
> if you feel you need `mach try` support.
>

On Sun, Sep 17, 2017 at 6:05 AM, Andrew Halberstadt
<ahalbe...@mozilla.com> wrote:
> Interesting, please file a bug either way and CC me. It worked
> for me back when it first landed, though I haven't tried it since.
> I'll see if I can reproduce sometime this week.

On 9/16/17 6:43 AM, Eric Rescorla wrote:
> On Fri, Sep 15, 2017 at 9:25 PM, Gregory Szorc <g...@mozilla.com> wrote:
>
>
>> I'd prefer to take a data-driven approach to answering the question of "do
>> we need to support vanilla Git." I wish I had local developer metrics or
>> results from a recent developer survey to feed into a decision. In lieu of
>> that data, I'd encourage users of vanilla Git to make noise on bug 1400470
>> if you feel you need `mach try` support.
>>
> This is not a good decision making procedure. First, requiring people to
> volunteer their objections inherently underweights those objections because
> it's work to do so. Second, the current situation has incentivized people
> to use cinnabar, so the number of vanilla git users is less than it
> otherwise would be. But this is bad, for the reasons I listed above. The
> right question is: what future do we want to live in, and that's a policy
> question, not one decided by taking a (highly biased) poll of what people
> currently do.

On Mon, Sep 18, 2017 at 6:05 AM, Eric Rescorla <e...@rtfm.com> wrote:>
I don't think that's true, for the reasons I indicated above. Rather,
> there's a policy decision about whether we are going to have Git as a
> first-class thing or whether we are going to continue force everyone who
> uses Git to fight with inadequate workflows. We know there are plenty of
> people who use Git.

On 18/09/17 04:05, Eric Rescorla wrote:

>> But that's just a general observation; if you look at this specific case,
>> it might not be much effort to support native git for richer/future try
>> pushing. But that's very different from requiring all the tools to support
>> native git on an equal basis. And it seems reasonable to evaluate the
>> utility of this specific support via a poll, even one known to be biased.
>>
>

> I don't think that's true, for the reasons I indicated above. Rather,
> there's a policy decision about whether we are going to have Git as a
> first-class thing or whether we are going to continue force everyone who
> uses Git to fight with inadequate workflows. We know there are plenty of
> people who use Git.

On Mon, Sep 18, 2017 at 1:10 AM, Henri Sivonen <hsiv...@hsivonen.fi> wrote:

> On Mon, Sep 18, 2017 at 6:05 AM, Eric Rescorla <e...@rtfm.com> wrote:>

> I don't think that's true, for the reasons I indicated above. Rather,
> > there's a policy decision about whether we are going to have Git as a
> > first-class thing or whether we are going to continue force everyone who
> > uses Git to fight with inadequate workflows. We know there are plenty of
> > people who use Git.
>

> Besides occasionally having to convert between hg and cinnabar
> changeset ids, what's inadequate about cinnabar workflow(s)?
>

>
> --
> Henri Sivonen
> hsiv...@hsivonen.fi
> https://hsivonen.fi/

> On 18/09/17 04:05, Eric Rescorla wrote:
>
> But that's just a general observation; if you look at this specific case,
>>> it might not be much effort to support native git for richer/future try
>>> pushing. But that's very different from requiring all the tools to
>>> support
>>> native git on an equal basis. And it seems reasonable to evaluate the
>>> utility of this specific support via a poll, even one known to be biased.
>>>
>>>

>> I don't think that's true, for the reasons I indicated above. Rather,
>> there's a policy decision about whether we are going to have Git as a
>> first-class thing or whether we are going to continue force everyone who
>> uses Git to fight with inadequate workflows. We know there are plenty of
>> people who use Git.
>>
>

Given none of those options seem to fit, the only other possibility I can
> think of is to skip the general problem of how to interact with the VCS for
> try specifically by making submitting to try not look like a VCS push, but
> like some other way of sending a blob of code to a remote machine (e.g.
> using some process that generates a patch file). But unless there's some
> extant way to achieve that it seems like it would be replacing
> known-working code (cinnabar) with new custom code.
>

> So my best guess is that you mean that all pushes should go via autoland
> and we should provide read-only hg/git repositories, and try pushes should
> also go via something other than a vcs push. But I'm probably missing
> something.

> 5. Allows vanilla git and hg on the client side, but requires
> something complex, custom, and scary on the server side to allow
> pushing to either repo. Could be possible if we eliminate ~all manual
> pushes (i.e. everything goes via autoland), but cinnabar or similar is
> still there in the background.

On Tue, Sep 19, 2017 at 8:40 AM, Aki Sasaki <asa...@mozilla.com> wrote:

> On 9/16/17 6:43 AM, Eric Rescorla wrote:
>

>
>
>
> On Mon, Sep 18, 2017 at 5:16 AM, Eric Rescorla <e...@rtfm.com> wrote:
>
>> And having something complex and scary on the server
>> side is (at least to me) obviously better than having something complex
>> and
>>  scary (and did I mention constantly out of date) on the client side,
>> because it's all in one place and externally just looks like the thing the
>> client is expecting. Note that we already have half of this because we
>> have
>> one-way synching to gecko-dev on the server side. Perhaps one could also
>> rip off some of the servo-gecko synching stuff here, but I don't know much
>> about how that's architected.
>>
>

>> >  5. Allows vanilla git and hg on the client side, but requires something
>> > complex, custom, and scary on the server side to allow pushing to either
>> > repo. Could be possible if we eliminate ~all manual pushes (i.e.
>> everything
>> > goes via autoland), but cinnabar or similar is still there in the
>> > background.
>> >
>>

On Tue, Sep 19, 2017 at 8:49 AM, Eric Rescorla <e...@rtfm.com> wrote:

> Generally no, but this is an unfortunate consequence of Mozilla's decision
> a while ago to pick a VCS which has not turned out to be the dominant
> choice (not placing blame here, but I think it's clear that's how it's
> turned out). The result is that a lot of people want to use git and that
> means git needs to have a first class experience.
>

> On Tue, Sep 19, 2017 at 8:49 AM, Eric Rescorla <e...@rtfm.com> wrote:
>
> > Generally no, but this is an unfortunate consequence of Mozilla's
> decision
> > a while ago to pick a VCS which has not turned out to be the dominant
> > choice (not placing blame here, but I think it's clear that's how it's
> > turned out). The result is that a lot of people want to use git and that
> > means git needs to have a first class experience.
> >
>
> I've been using git for years now to develop Firefox, and I feel like it is
> a first class experience. There's a one time cost to setting up cinnabar,
> but after that, everything just works, including |mach try| and |mach
> mozreview|. It is still probably less setup than Mercurial users have to go
> through to install enough extensions to make hg usable. ;) Sure, there's a
> bit of "wacky custom machinery", but developers using hg also have to deal
> with some of that, so that's more of a Firefox developer problem than a git
> Firefox developer problem.
>

On 9/16/17 6:43 AM, Eric Rescorla wrote:

> 2. There are a lot more people writing code for Firefox than developing the
> internal tools, so in general, costs on those people should be avoided.

On Mon, Sep 18, 2017 at 5:16 AM, Eric Rescorla <e...@rtfm.com> wrote:

> And having something complex and scary on the server
> side is (at least to me) obviously better than having something complex and
>  scary (and did I mention constantly out of date) on the client side,
> because it's all in one place and externally just looks like the thing the
> client is expecting. Note that we already have half of this because we have
> one-way synching to gecko-dev on the server side. Perhaps one could also
> rip off some of the servo-gecko synching stuff here, but I don't know much
> about how that's architected.
>

I might be reading the first statement wrong: I see that as an argument to
avoid putting more costs on the people who develop and maintain internal
tools, because it's a smaller group. If this is an accurate reading, then
the second paragraph appears to be contradictory: moving the pain and
complexity around git from all Firefox developers onto this smaller group
will increase costs for that smaller group. From my perspective, gecko-dev
conversions have largely been as smooth as can be expected for the past
number of years, but we're seeing more timeouts, and it may only be a
matter of time before we either need to sink significant internal tools
development time into the conversion script, or we hit an issue that causes
significant downtime.

If I'm reading wrong, and you're saying we need to avoid putting costs on
the larger Firefox development group, then the two statements are
non-contradictory. I do think expecting supporting 2 VCSes as seamlessly as
one is a large ask of the smaller team; do many other software projects
support multiple official VCSes and workflows?