Re: Proposed W3C Charter: Hardware Security Working Group

[L. David Baron]

I'm currently planning to submit the following as a comment on the
charter (mostly based on what Richard wrote, but somewhat reworded).
Please let me know if you think this needs rewording.

-David

[X] Opposes this charter and requests that the group not be created
[Formal Objection]

The proposed charter does not list concrete deliverables, and many
of the previous proposals within this scope have been opposed
several times by browser vendors, for example because hardware
assets exposed to Javascript can be used as super-cookies, creating
a serious privacy concern.

Work in this space should happen in a community group or similar
forum until there are clearly identified deliverables, and those
deliverables have a clear explanation of how they fit with the Web's
security model and with the privacy interests of users.

We continue to support the related but better-focused work that is
happening in the Web Authentication WG and the Web Payments WG.

On Tuesday 2016-03-01 18:32 -0500, Richard Barnes wrote:
> Mozilla should oppose the formation of this working group.  The charter
> fails to specify concrete deliverables, and many of the potential
> deliverables listed have been opposed several times by browser vendors,
> e.g., because hardware assets exposed to JS can be used as super-cookies.
> 
> If anything is to be done here, it should be done in a community group or
> other forum until they have a story for what exactly they will be
> developing and how it fits with the web security model.
> 
> On Mon, Feb 29, 2016 at 8:34 PM, L. David Baron  wrote:
> 
> > The W3C is proposing a charter for:
> >
> >   Hardware Security Working Group
> >   https://www.w3.org/2015/hasec/2015-hasec-charter.html
> >   https://lists.w3.org/Archives/Public/public-new-work/2016Feb/0009.html
> >
> > Mozilla has the opportunity to send comments or objections through
> > Friday, April 1.
> >
> > Please reply to this thread if you think there's something we should
> > say as part of this charter review.
> >
> > (My understanding is that there is some concern that this work could
> > create supercookie-like features, which would be bad.)
> >
> > -David
> >
> > --
> > 𝄞   L. David Baron http://dbaron.org/   𝄂
> > 𝄢   Mozilla  https://www.mozilla.org/   𝄂
> >  Before I built a wall I'd ask to know
> >  What I was walling in or walling out,
> >  And to whom I was like to give offense.
> >- Robert Frost, Mending Wall (1914)
> >
> > ___
> > dev-platform mailing list
> > dev-platform@lists.mozilla.org
> > https://lists.mozilla.org/listinfo/dev-platform
> >
> >
> ___
> dev-platform mailing list
> dev-platform@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform

-- 
𝄞   L. David Baron http://dbaron.org/   𝄂
𝄢   Mozilla  https://www.mozilla.org/   𝄂
 Before I built a wall I'd ask to know
 What I was walling in or walling out,
 And to whom I was like to give offense.
   - Robert Frost, Mending Wall (1914)


signature.asc
Description: Digital signature
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Proposed W3C Charter: Pointer Events Working Group

[L. David Baron]

On Wednesday 2016-03-02 07:34 -0800, Matt Brubeck wrote:
> I think that Mozilla should comment in favor of the PEWG charter. Mozilla has 
> been participating in the WG and it is doing important work for interop and 
> performance of pointer input handling.

OK, I'll vote in support of the charter, then.  (I don't have any
comments to make.)

-David

-- 
𝄞   L. David Baron http://dbaron.org/   𝄂
𝄢   Mozilla  https://www.mozilla.org/   𝄂
 Before I built a wall I'd ask to know
 What I was walling in or walling out,
 And to whom I was like to give offense.
   - Robert Frost, Mending Wall (1914)


signature.asc
Description: Digital signature
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Submit to MozReview using Git

[Tim Guan-tin Chien]

Thanks for the pointer! I ended up re-do the cloning from hg instead.

I would recommend the mozreview docs points to these document and explicit
states the origin of local clone mozreview is supposedly to work with.


Tim

On Wed, Mar 2, 2016 at 6:13 PM, Ting-Yu Lin  wrote:

> > ~/repo/gecko/gecko-dev master$ git mozreview configure
> > searching for appropriate review repository...
> > warning: error trying to resolve Mercurial changesets
>
> I saw the same error before. After setting mozilla-central in my git repo
> remote described in the following wiki, I can setup review repository
> successfully. I'm not sure this is a require steps because the manual to
> setup mozview by using git may assume the git repo was fresh cloned by
> git-cinnabar.
>
>
> https://github.com/glandium/git-cinnabar/wiki/Mozilla:-Using-a-git-clone-of-gecko%E2%80%90dev-to-push-to-mercurial#switching-to-git-cinnabar
>
>
> Ting-Yu
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Proposing preferring Clang over GCC for developer buidls

[Benoit Girard]

Note that, as you say, the debugging information produced by the compiler
and the debugger that consumes it are completely orthogonal. I've tried
several times to use lldb but I keep coming back to GDB. Particularly now
with RR+GDB it's light years ahead.

I find that GDB works quite well with the information that clang generates.
That's what I use day-to-day.

On Wed, Mar 2, 2016 at 6:48 PM, Bill McCloskey 
wrote:

> Is the debugging information generated by clang as good or better than
> GCC's? My experience with lldb has been terrible, but that may have more to
> do with the debugger itself than with the information clang generates.
>
> -Bill
>
> On Wed, Mar 2, 2016 at 2:50 PM, Gregory Szorc  wrote:
>
> > Over in bug 1253064 I'm proposing switching developer builds to prefer
> > Clang over GCC because the limited numbers we have say that Clang can
> build
> > mozilla-central several minutes faster than GCC (13 minutes vs 17.5 on my
> > I7-6700K). I'm not proposing switching what we use to produce builds in
> > automation. I'm not proposing dropping GCC support. This is all about
> > choosing faster defaults so people don't spend as much time waiting for
> > builds to complete and become more productive as a result.
> >
> > Please comment on the bug if you have something to add.
> > ___
> > dev-platform mailing list
> > dev-platform@lists.mozilla.org
> > https://lists.mozilla.org/listinfo/dev-platform
> >
> ___
> dev-platform mailing list
> dev-platform@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Proposing preferring Clang over GCC for developer buidls

[Xidorn Quan]

On Thu, Mar 3, 2016 at 6:50 AM, Gregory Szorc  wrote:
> Over in bug 1253064 I'm proposing switching developer builds to prefer
> Clang over GCC because the limited numbers we have say that Clang can build
> mozilla-central several minutes faster than GCC (13 minutes vs 17.5 on my
> I7-6700K). I'm not proposing switching what we use to produce builds in
> automation. I'm not proposing dropping GCC support. This is all about
> choosing faster defaults so people don't spend as much time waiting for
> builds to complete and become more productive as a result.

I wonder whether we could get some speedup from using Clang/C2 [1]
by default on Windows. It's probably worth investigating in the future
as well.

[1] 
https://blogs.msdn.microsoft.com/vcblog/2015/12/04/clang-with-microsoft-codegen-in-vs-2015-update-1/

- Xidorn
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Proposing preferring Clang over GCC for developer buidls

[Jeff Gilbert]

On Wed, Mar 2, 2016 at 3:45 PM, Mike Hommey  wrote:
> More importantly, changing the official toolchain has implications on
> performance.

Sorry, I meant for general automation. Our final spins (especially
LTO/PGO builds) should remain whatever gives us maximum perf. (not
making any claims myself here!)

Our PGO/LTO builds can take 10x+ what our normal integration builds
take if it nets us a few percentage points of runtime perf.

I suppose it becomes a question of divergence between fast-building
builds and 'final' PGO/fully-optimized builds. We already have this to
some extent with PGO vs non-PGO builds.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Proposing preferring Clang over GCC for developer buidls

[Martin Thomson]

On Thu, Mar 3, 2016 at 10:45 AM, Mike Hommey  wrote:
> More importantly, changing the official toolchain has implications on
> performance.

Without any real evidence for this, I'm told that GCC still produces
better (i.e., faster) output.  But we could switch try builds to clang
if the time savings are that good.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Proposing preferring Clang over GCC for developer buidls

[Bill McCloskey]

Is the debugging information generated by clang as good or better than
GCC's? My experience with lldb has been terrible, but that may have more to
do with the debugger itself than with the information clang generates.

-Bill

On Wed, Mar 2, 2016 at 2:50 PM, Gregory Szorc  wrote:

> Over in bug 1253064 I'm proposing switching developer builds to prefer
> Clang over GCC because the limited numbers we have say that Clang can build
> mozilla-central several minutes faster than GCC (13 minutes vs 17.5 on my
> I7-6700K). I'm not proposing switching what we use to produce builds in
> automation. I'm not proposing dropping GCC support. This is all about
> choosing faster defaults so people don't spend as much time waiting for
> builds to complete and become more productive as a result.
>
> Please comment on the bug if you have something to add.
> ___
> dev-platform mailing list
> dev-platform@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Proposing preferring Clang over GCC for developer buidls

[Mike Hommey]

On Wed, Mar 02, 2016 at 03:21:14PM -0800, Gregory Szorc wrote:
> On Wed, Mar 2, 2016 at 3:15 PM, Jeff Gilbert  wrote:
> 
> > For standard development builds, --enable-debug build speed is (to me)
> > the primary motivator since we've guaranteed that they're equally
> > correct. (within reason) I'll gladly run some extra tests to gather
> > data about this.
> >
> > FWIW, with a 26% speedup, it would definitely seems like it'd be worth
> > investigating also for automation. Is anyone/anybug driving that?
> >
> 
> Automation is a trickier subject because if we change the "official"
> toolchain that has implications for down-stream packagers, who will likely
> want to follow suit.

More importantly, changing the official toolchain has implications on
performance.

Mike
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Proposing preferring Clang over GCC for developer buidls

[Gregory Szorc]

On Wed, Mar 2, 2016 at 3:15 PM, Jeff Gilbert  wrote:

> For standard development builds, --enable-debug build speed is (to me)
> the primary motivator since we've guaranteed that they're equally
> correct. (within reason) I'll gladly run some extra tests to gather
> data about this.
>
> FWIW, with a 26% speedup, it would definitely seems like it'd be worth
> investigating also for automation. Is anyone/anybug driving that?
>

Automation is a trickier subject because if we change the "official"
toolchain that has implications for down-stream packagers, who will likely
want to follow suit. I'd rather keep our scope limited to developer builds
for now so we postpone opening the can of worms. Also, glandium claims GCC
is a bit better with ccache. And given our higher cache hit rate in
automation due to using S3 as a global cache, that may make GCC faster than
Clang in automation. Need moar data.


>
> On Wed, Mar 2, 2016 at 2:50 PM, Gregory Szorc  wrote:
> > Over in bug 1253064 I'm proposing switching developer builds to prefer
> > Clang over GCC because the limited numbers we have say that Clang can
> build
> > mozilla-central several minutes faster than GCC (13 minutes vs 17.5 on my
> > I7-6700K). I'm not proposing switching what we use to produce builds in
> > automation. I'm not proposing dropping GCC support. This is all about
> > choosing faster defaults so people don't spend as much time waiting for
> > builds to complete and become more productive as a result.
> >
> > Please comment on the bug if you have something to add.
> > ___
> > dev-platform mailing list
> > dev-platform@lists.mozilla.org
> > https://lists.mozilla.org/listinfo/dev-platform
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Proposing preferring Clang over GCC for developer buidls

[Jeff Gilbert]

For standard development builds, --enable-debug build speed is (to me)
the primary motivator since we've guaranteed that they're equally
correct. (within reason) I'll gladly run some extra tests to gather
data about this.

FWIW, with a 26% speedup, it would definitely seems like it'd be worth
investigating also for automation. Is anyone/anybug driving that?

On Wed, Mar 2, 2016 at 2:50 PM, Gregory Szorc  wrote:
> Over in bug 1253064 I'm proposing switching developer builds to prefer
> Clang over GCC because the limited numbers we have say that Clang can build
> mozilla-central several minutes faster than GCC (13 minutes vs 17.5 on my
> I7-6700K). I'm not proposing switching what we use to produce builds in
> automation. I'm not proposing dropping GCC support. This is all about
> choosing faster defaults so people don't spend as much time waiting for
> builds to complete and become more productive as a result.
>
> Please comment on the bug if you have something to add.
> ___
> dev-platform mailing list
> dev-platform@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Proposing preferring Clang over GCC for developer buidls

[Gregory Szorc]

Over in bug 1253064 I'm proposing switching developer builds to prefer
Clang over GCC because the limited numbers we have say that Clang can build
mozilla-central several minutes faster than GCC (13 minutes vs 17.5 on my
I7-6700K). I'm not proposing switching what we use to produce builds in
automation. I'm not proposing dropping GCC support. This is all about
choosing faster defaults so people don't spend as much time waiting for
builds to complete and become more productive as a result.

Please comment on the bug if you have something to add.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to implement: DOM Push API in Firefox for Android

[Martin Thomson]

This is great.

As I said elsewhere, I don't think that we can pref this on until bug
1252650 lands.  It turns out that "gecko not running" is pretty much
the only interesting state for push.

On Thu, Mar 3, 2016 at 5:06 AM, Nicholas Alexander
 wrote:
> Summary: "The Push API gives web applications the ability to receive
> messages pushed to them from a server, whether or not the web app is in the
> foreground, or even currently loaded, on a user agent. This lets developers
> deliver asynchronous notifications and updates to users that opt in,
> resulting in better engagement with timely new content."
>
> Bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1206207
>
> Link to standard: https://w3c.github.io/push-api/
>
> Platform coverage: Firefox for Android.  This is already shipping in
> Firefox Desktop:
> the Firefox Desktop intent to implement message is at [1] and the intent to
> ship message is at [2].
>
> Estimated or target release: Firefox for Android 47 is desired.  48 seems
> most likely.
>
> Preference behind which this will be implemented: this is both behind a
> build flag (due to Android-specific permission changes, etc) and behind
> dom.push.enabled.
>
> DevTools bug: this should be covered by the Desktop devtools ticket:
> https://bugzilla.mozilla.org/show_bug.cgi?id=1214248.
>
> Best,
> Nick
>
> [1] https://lists.mozilla.org/pipermail/dev-platform/2014-July/005828.html
> [2]
> https://groups.google.com/d/msg/mozilla.dev.platform/vU4NsuKhTOY/wc2PviRUBAAJ
> ___
> dev-platform mailing list
> dev-platform@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to implement: DOM Push API in Firefox for Android

[David Rajchenbach-Teller]

This would be extremely useful for Project Link and, I assume, other
Connected Devices projects.

Cheers,
 David

On 02/03/16 19:06, Nicholas Alexander wrote:
> Summary: "The Push API gives web applications the ability to receive
> messages pushed to them from a server, whether or not the web app is in the
> foreground, or even currently loaded, on a user agent. This lets developers
> deliver asynchronous notifications and updates to users that opt in,
> resulting in better engagement with timely new content."
> 
> Bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1206207
> 
> Link to standard: https://w3c.github.io/push-api/
> 
> Platform coverage: Firefox for Android.  This is already shipping in
> Firefox Desktop:
> the Firefox Desktop intent to implement message is at [1] and the intent to
> ship message is at [2].
> 
> Estimated or target release: Firefox for Android 47 is desired.  48 seems
> most likely.
> 
> Preference behind which this will be implemented: this is both behind a
> build flag (due to Android-specific permission changes, etc) and behind
> dom.push.enabled.
> 
> DevTools bug: this should be covered by the Desktop devtools ticket:
> https://bugzilla.mozilla.org/show_bug.cgi?id=1214248.
> 
> Best,
> Nick
> 
> [1] https://lists.mozilla.org/pipermail/dev-platform/2014-July/005828.html
> [2]
> https://groups.google.com/d/msg/mozilla.dev.platform/vU4NsuKhTOY/wc2PviRUBAAJ
> ___
> dev-platform mailing list
> dev-platform@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
> 
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Intent to implement: DOM Push API in Firefox for Android

[Nicholas Alexander]

Summary: "The Push API gives web applications the ability to receive
messages pushed to them from a server, whether or not the web app is in the
foreground, or even currently loaded, on a user agent. This lets developers
deliver asynchronous notifications and updates to users that opt in,
resulting in better engagement with timely new content."

Bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1206207

Link to standard: https://w3c.github.io/push-api/

Platform coverage: Firefox for Android.  This is already shipping in
Firefox Desktop:
the Firefox Desktop intent to implement message is at [1] and the intent to
ship message is at [2].

Estimated or target release: Firefox for Android 47 is desired.  48 seems
most likely.

Preference behind which this will be implemented: this is both behind a
build flag (due to Android-specific permission changes, etc) and behind
dom.push.enabled.

DevTools bug: this should be covered by the Desktop devtools ticket:
https://bugzilla.mozilla.org/show_bug.cgi?id=1214248.

Best,
Nick

[1] https://lists.mozilla.org/pipermail/dev-platform/2014-July/005828.html
[2]
https://groups.google.com/d/msg/mozilla.dev.platform/vU4NsuKhTOY/wc2PviRUBAAJ
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Proposed W3C Charter: Pointer Events Working Group

[Matt Brubeck]

I think that Mozilla should comment in favor of the PEWG charter. Mozilla has 
been participating in the WG and it is doing important work for interop and 
performance of pointer input handling.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: APNG and Accept-Encoding

[maxstepin]

I think now, in 2010s most of internet content is made by regular users, not 
webdevs. Can we look at the problem from their perspective? Of course, CDNs and 
webdevs care about MIME types and Accept headers, but regular users know 
nothing about that and they've been happily posting apngs to Tumblr and 
DeviantArt for years now:

http://patakk.tumblr.com/post/42213491263 
http://kokotea.deviantart.com/art/AT-kia-animated-PNG-519985556
http://www.deviantart.com/art/Lifealope-293147967
http://apngden.tumblr.com/

They simply tell their visitors: "you can use Firefox, or click here for APNG 
extension for Chrome, or click here for the GIF version". Judging by the 
comments, viewers seems to figure it out quickly.

So what would happen if APNG support lands into Chrome "as is" and only IE/Edge 
is left out? These artistic types would keep posting that stuff, only a bit 
more often. What about CDNs and webdevs of big websites? Maybe a few of them 
would UA-sniff IE/Edge, but most won't bother they'll keep using GIFs. A few 
might switch to APNG exclusively, but that's hard to predict.

I think the net effect would be slightly positive.

And if Edge devs would follow soon enough, the whole thing could be moot, 
quickly. Three-way negotiations seems harder to achieve than convincing just 
one more player.

Max.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Talos e10s dashboard

[Gabor Krizsanits]

I've just visited guardian.co.uk, *(Bug 1252822*
) scrolling seems
quite bad... :(

On Wed, Mar 2, 2016 at 12:29 AM, Chris Peterson 
wrote:

> On 3/1/16 9:57 AM, William Lachance wrote:
>
>> Also, mconley suggested being able to compare the results of individual
>> subtests. You can access this view for any given talos test by hovering
>> over the line in the comparison and selecting "subtests". This sometimes
>> give interesting data, for instance on "tps" some pages are clearly
>> causing more problems than others:
>>
>>
>> https://treeherder.allizom.org/perf.html#/e10s_comparesubtest?baseSignature=fe016968d213834efd424ca88680cfa7490b6c09&e10sSignature=5c199ff7bd97284c5f3820ba908f92275620cd8b
>>
>>
>> (notice how aljaazera.net has a consistent ~450% regression!)
>>
>
> This looks great, Will. Good catch on the aljazeera.net problem. The
> other outliers are mail.ru (at ~410% regression) and guardian.co.uk (at
> ~380% regression). We should probably file bugs for those individual sites.
> :)
>
>
> ___
> dev-platform mailing list
> dev-platform@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: firefox-ui-tests are now in mozilla-central with TaskCluster support

[Henrik Skupin]

Matthew N. wrote on 03/01/2016 06:18 PM:

> Could you give an overview of what is tested by this suite and how it 
> differs from mochitest-browser-chrome? It seems one difference is that 
> some(?) tests run on non-en-US.

So Andrew already told a lot, and just to emphasize here we really do
not want to work with any JS globals etc when navigating through the ui
but always use ui elements directly. The reason is that we also run our
tests with a couple of other locales and for each of those the command,
access keys and others can differ.

The before mentioned firefox-puppeteer library is a helper to make test
creation even more easier. So you don't have to remember the real DOM
id, label, anon attribute or what-ever when accessing such elements. We
have a nice hierarchy like:

self.browser.navbar.back_button.click()

The number of tests are still low given that we haven't had the time to
port more tests from mozmill. That means as of now we have converted
only the most important tests including remote security checks for
various protocols and some locationbar and privatebrowsing tests. We
would like to get more tests added especially those which would require
a restart of Firefox, or those for testing shortcuts etc across locales.
So we hope that you all might want to create one in case you have a need
for.

> Could you also add a description to 
> https://developer.mozilla.org/en-US/docs/Mozilla/QA/Automated_testing?

Yes I will and this is actually one of my remaining goals this quarter.
The work for that will be tracked on bug 1237552.

In case you want to know more about the code right now, you can find
everything here:

http://mxr.mozilla.org/mozilla-central/source/testing/puppeteer/firefox/
http://mxr.mozilla.org/mozilla-central/source/testing/firefox-ui/

Let me know if there are still open questions.

-- 
Henrik
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Submit to MozReview using Git

[Ting-Yu Lin]

> ~/repo/gecko/gecko-dev master$ git mozreview configure
> searching for appropriate review repository...
> warning: error trying to resolve Mercurial changesets

I saw the same error before. After setting mozilla-central in my git repo
remote described in the following wiki, I can setup review repository
successfully. I'm not sure this is a require steps because the manual to
setup mozview by using git may assume the git repo was fresh cloned by
git-cinnabar.

https://github.com/glandium/git-cinnabar/wiki/Mozilla:-Using-a-git-clone-of-gecko%E2%80%90dev-to-push-to-mercurial#switching-to-git-cinnabar


Ting-Yu
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Submit to MozReview using Git

[Tim Guan-tin Chien]

Hi :gps,

I am following the description here and try to set up git-mozreview on my
local gecko-dev clone. Here is the error I got:

~/repo/gecko/gecko-dev master$ git mozreview configure
searching for appropriate review repository...
warning: error trying to resolve Mercurial changesets

Could you recommend how I should debug this? All repo was cloned yesterday
and git/mercurial are all up-to-date from Homebrew

$ git --version
git version 2.7.2
$ hg --version
Mercurial Distributed SCM (version 3.7.1)

Thanks!


Tim



On Fri, Feb 12, 2016 at 11:05 PM, Wander Lairson Costa 
wrote:

> \o/
>
> 2016-02-05 19:05 GMT-02:00 Nicholas Alexander :
> > On Fri, Feb 5, 2016 at 12:24 PM, Gregory Szorc  wrote:
> >
> >> It is now possible to submit reviews to MozReview using Git.
> Instructions
> >> are at
> >>
> >>
> https://mozilla-version-control-tools.readthedocs.org/en/latest/mozreview/install-git.html
> >>
> >> Bugs should be filed against Developer Services :: MozReview.
> #mozreview is
> >> your support IRC channel.
> >>
> >
> > Wow!  Great work gps and everybody else  involved!
> >
> > Nick
> > ___
> > dev-version-control mailing list
> > dev-version-cont...@lists.mozilla.org
> > https://lists.mozilla.org/listinfo/dev-version-control
>
>
>
> --
> Cheers,
> Wander
> ___
> dev-platform mailing list
> dev-platform@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform