Re: Intent to require `mach try` for submitting to Try

On Mon, Sep 18, 2017 at 6:05 AM, Eric Rescorla 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 i

Re: Intent to require `mach try` for submitting to Try

In a rare case that we need to send a "CLOSED TREE" try job, will we be able to do that with ./mach try? Last time I didn't use mach try to submit try job was because of that. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.moz

Re: Intent to require `mach try` for submitting to Try

On 18/09/17 09:27, Samael Wang wrote: In a rare case that we need to send a "CLOSED TREE" try job, will we be able to do that with ./mach try? Last time I didn't use mach try to submit try job was because of that. That doesn't work right now, but it should be easy to add a --closed-tree flag

Re: Intent to require `mach try` for submitting to Try

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 i

[Firefox Desktop] Issues found: September 11th to September 15th

Hi everyone, Here's the list of new issues found and filed by the Desktop Release QA Team last week, *September 11 - September 15* (week 37). Additional details on the team's priorities last week, as well as the plans for the current week are available at: https://public.etherpad-mozilla

Re: Intent to require `mach try` for submitting to Try

On Mon, Sep 18, 2017 at 1:10 AM, Henri Sivonen wrote: > On Mon, Sep 18, 2017 at 6:05 AM, Eric Rescorla 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

Re: Intent to require `mach try` for submitting to Try

On Mon, Sep 18, 2017 at 2:56 AM, James Graham wrote: > 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 requ

Re: Race Cache With Network experiment on Nightly

Em quarta-feira, 24 de maio de 2017 12:36:45 UTC-3, Valentin Gosu escreveu: > As part of the Quantum Network initiative we are working on a project > called "Race Cache With Network" (rcwn) [1]. > > This project changes the way the network cache works. When we detect that > disk IO may be slow, w

Canonical cinnabar repository

This message was inspired by the `mach try` thread but is off-topic there so I think deserves its own thread. It seems to me that a lot of people are now assuming a cinnabar repo is the canonical way for git users to develop on mozilla-central. If we want to make this mozilla policy I don't really

Re: Intent to require `mach try` for submitting to Try

On Fri, Sep 15, 2017 at 10:21 PM, ISHIKAWA,chiaki wrote: > Does "mozilla/mach try" will work for try-comm-central? > > (Well, I know there has been a general talk of moving thunderbird to > somewhere else, but it is not going to happen overnight.) > I'm not sure. There's no good reason why it sh

Re: Intent to require `mach try` for submitting to Try

James Graham 2017 September 18 at 02:56 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 go

Re: Canonical cinnabar repository

Kartikaya Gupta 2017 September 18 at 07:05 It seems to me that a lot of people are now assuming a cinnabar repo is the canonical way for git users to develop on mozilla-central. If we want to make this mozilla policy I don't really have objections, but I think that if w

Re: Canonical cinnabar repository

I agree having a canonical version would be very valuable. In the mean time if you want to avoid having to do the entire conversion locally you can start by cloning the cinnabar branch of https://github.com/jrmuizel/gecko-cinnabar which is a local full conversion that I painfully uploaded to github

Re: Canonical cinnabar repository

On Mon, Sep 18, 2017 at 7:05 AM, Kartikaya Gupta wrote: > I've tried using cinnabar a couple of times now and the last time I > tried, this was the dealbreaker for me. My worfklow often involves > moving a branch from one machine to another and the extra hassle that > results from mismatched SHAs

Re: Canonical cinnabar repository

I've had quite a few times (every time I get a new machine) that I've had issues with git-cinnabar and multiple machines. This has resulted in me just scp'ing my entire repo every time I get a new machine (which comes with its own set of issues... messed up paths in the .git/config, for example). I

Re: Canonical cinnabar repository

On Mon, Sep 18, 2017 at 11:04 AM, Myk Melez wrote: > Having said that, I agree that it's worth enabling developers to clone a > canonical Git repo. I've been syncing mozilla/gecko using cinnabar for a > while to experiment with ways of doing this. That's great, thanks. If we can do something like

Re: Canonical cinnabar repository

A few posts here and in the other thread have mentioned abstracting away complexity to servers as if it is a magical solution that makes all problems go away. Yes, deploying a server-side solution to do some "syncing" is doable and solves a subset of notable problems. But I advise extreme caution

Re: Canonical cinnabar repository

On Mon, Sep 18, 2017 at 8:25 AM, Andrew McCreight wrote: > On Mon, Sep 18, 2017 at 7:05 AM, Kartikaya Gupta > wrote: > > > I've tried using cinnabar a couple of times now and the last time I > > tried, this was the dealbreaker for me. My worfklow often involves > > moving a branch from one machi

Re: Canonical cinnabar repository

On 09/18/2017 01:16 PM, Bobby Holley wrote: On Mon, Sep 18, 2017 at 8:25 AM, Andrew McCreight wrote: On Mon, Sep 18, 2017 at 7:05 AM, Kartikaya Gupta wrote: I've tried using cinnabar a couple of times now and the last time I tried, this was the dealbreaker for me. My worfklow often involves

Re: Canonical cinnabar repository

FWIW, https://github.com/jrmuizel/gecko-cinnabar doesn't have the CVS history so is no better than https://github.com/mozilla/gecko. Having a canonical repo that includes the CVS history will make the SHA's incompatible with doing a direct conversion of hg which is a disadvantage. I'm not sure what

Re: Canonical cinnabar repository

CVS history feels like an odd bar for cinnabar. The goal of cinnabar is to enable seamless integration between git and mercurial with reproducible, 1:1 commit mappings. Our canonical mercurial repositories don't have CVS history, so we shouldn't expect the cinnabar clones of those repositories to h

Re: Canonical cinnabar repository

On 09/18/2017 02:35 PM, Jeff Muizelaar wrote: FWIW, https://github.com/jrmuizel/gecko-cinnabar doesn't have the CVS history so is no better than https://github.com/mozilla/gecko. Right. Jeff corrected my confusion on IRC. His repo has both lines of history, and the cinnabar conversion is on

Re: Canonical cinnabar repository

On 09/18/2017 03:30 PM, Bobby Holley wrote: CVS history feels like an odd bar for cinnabar. The goal of cinnabar is to enable seamless integration between git and mercurial with reproducible, 1:1 commit mappings. Our canonical mercurial repositories don't have CVS history, so we shouldn't expec