Re: Why is Mozreview hassling me about squashed commits?

On Sat, Apr 2, 2016 at 5:51 PM, Eric Rescorla wrote: > On Sat, Apr 2, 2016 at 5:59 PM, Gregory Szorc wrote: > >> When you say "I almost never want to review individual commits and >> instead want to review the changeset as a single diff," I'm confused >> because

Re: Run firefox as headless???

If xvfb doesn't work for you then as far as I know there's no way for it to be truly headless unfortunately. Looks like slimerjs is trying to to solve this issue: https://github.com/laurentj/slimerjs/issues/80 They mention using createWindowlessBrowser but I'm not familiar with it. On Thu, Apr

Re: Run firefox as headless???

If the problem is that you're running on a windowless system, you can use xfvb-run to launch your application On Thu, Apr 7, 2016 at 5:11 PM, Devan Shah wrote: > slimerjs is not fully headless unless using xvfb, is there anything else > that can he used. >

Re: Run firefox as headless???

slimerjs is not fully headless unless using xvfb, is there anything else that can he used. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform

Re: Run firefox as headless???

Check out slimerjs: https://slimerjs.org/ On Thu, Apr 7, 2016 at 6:50 PM, Devan Shah wrote: > Is it possible to run firefox in headless form to fetch url and get the > full Dom as rendered. Same way it would render on normal foredox >

Re: Triage Plan for Firefox Components

You might be able to create views into these triage queue's with combinations of existing keywords and maybe a few added ones. For example: Can reproduce Can others reproduce the problem described? has the inverse represented by needs-testcase for example. In the case of the

Run firefox as headless???

Is it possible to run firefox in headless form to fetch url and get the full Dom as rendered. Same way it would render on normal foredox ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform

Re: Triage Plan for Firefox Components

First: there's that Bugzilla Anthropology project ( https://wiki.mozilla.org/Bugzilla_Anthropology) thanks. I'd heard mention of it and asked around. What we found during the pilot, and the Platform Team has found in their triage, is that list of bugs with needinfo? is I'm worried that multiple

Re: MozReview's interdiffs

Thanks for the info, Mark. In the mean time, at least, it would make interdiffs easiest to read if patch authors can submit updates to patches against the same revision as the original patches. If that causes too much inconvenience (and it will sometimes), then separate pushes for the rebase and

MozReview's interdiffs

MozReview, specifically, Review Board, has a number of bugs related to interdiffs[1]. Many of these bugs are related to Review Board's algorithms to filter out changes caused by rebases (as opposed to intentional updates to commits). Both the MozReview and the Review Board teams have done some

Re: Triage Plan for Firefox Components

re: Determining answers to any or all of the above might require multiple rounds of dialog, and some of them need to be understood in sequence rather than in parallel. They also require very different sets of expertise to determine. Yes! We should set up systems and process and

[desktop][mobile] Firefox 46 release moved up a week to April 26

Hello dev-platform and firefox-dev, We are delaying the release of Firefox 46 for a week. Short version: For the Firefox 46 cycle, merge day is now April 25. Release is April 26. The 47 release schedule hasn't changed; release still planned for June 7. Here are some details: During the 46

Re: Crash signature change: signatures now include abort messages

We are going to revert this change for now to unblock our release process, since it is clear that some changes need to be made, and I will be out all of next week. Now is the time to make comments about how that feature should behave! :) https://bugzilla.mozilla.org/show_bug.cgi?id=803779 On

Re: Crash signature change: signatures now include abort messages

Sorry, that "look at the signatures" link should have been https://crash-stats.allizom.org/search/?product=Firefox=%5EAbort&_facets=signature&_columns=date&_columns=signature&_columns=abort_message#facet-signature I propose that before we add it to the signature, we remove /^\[.+\] ###!!!

Re: Crash signature change: signatures now include abort messages

For one thing, the signature facet is more helpful to look at signatures: Abort&_facets=signature&_columns=date&_columns=signature&_columns=abort_message#facet-signature ;-) Hmm, I'm somewhat nervous about the fact that there is no signature that appears twice in this stage dataset. I think

Re: Triage Plan for Firefox Components

On Wednesday 2016-04-06 18:47 -0700, Emma Humphries wrote: > Following up on yesterday's email: I put together a draft second proposal > and shopped it around some, and now I want to bring that back into the main > discussion. > > The bullet point version of this is: > > * Add a binary field

TortoiseHg/TortoiseSVN (was: Upcoming SSH Host Key Rotation for hg.mozilla.org)

On 04/04/2016 23:52, Gregory Szorc wrote: > We also changed the SSH server config to only support the "modern" set of > ciphers, MACs, algorithms, etc from > https://wiki.mozilla.org/Security/Guidelines/OpenSSH#Modern. If you are > running an old SSH client, it may not be able to connect. > > If