Running that mach try command with the additional --no-push argument
produces this mouthful:
try: -b do -p linux64 -u
crashtest,crashtest-e10s,mochitest-1,mochitest-browser-chrome-1,mochitest-e10s-1,mochitest-e10s-browser-chrome-1,mochitest-o,reftest,reftest-e10s,xpcshell
-t none --try-test-paths
On Wed, Apr 27, 2016 at 12:33 PM, smaug wrote:
> On 04/26/2016 01:47 PM, Ehsan Akhgari wrote:
>
>> On 2016-04-26 1:02 PM, Mike Hommey wrote:
>>
>>> On Mon, Apr 25, 2016 at 10:52:02PM -0400, Boris Zbarsky wrote:
>>>
On 4/25/16 10:34 PM, Mike Hommey wrote:
> Don't we already have that
On 04/26/2016 10:31 AM, Ehsan Akhgari wrote:
On 2016-04-25 10:58 PM, Boris Zbarsky wrote:
That said, note that a bunch of the items above lie somewhat out of a
specific module, so it's not clear to me that we want intent-to-ship OKs
to be module-specific.
Yeah, a bunch of stuff definitely cros
On 04/26/2016 01:47 PM, Ehsan Akhgari wrote:
On 2016-04-26 1:02 PM, Mike Hommey wrote:
On Mon, Apr 25, 2016 at 10:52:02PM -0400, Boris Zbarsky wrote:
On 4/25/16 10:34 PM, Mike Hommey wrote:
Don't we already have that with superreviewers?
Kinda, sorta.
(How outdated is that list, btw?)
Qu
On Saturday, April 23, 2016 at 6:25:36 AM UTC+10, Gregory Szorc wrote:
> Visual Studio 2015 Update 2 was released just days after we switched
> automation from VS2013 to VS2015 Update 1. We know we were going to take
> Update 2 eventually and we didn't want to run a Windows toolchain for as
> short
On Tue, Apr 26, 2016 at 03:49:11PM +0200, Gabor Krizsanits wrote:
> As someone who was high on the list of try server usage for two
> weeks My problem was a test I tried to fix for both e10s and
> non-e10s, and it timed out _sometimes_ on _some_ platforms even
> depending on debug/release buil
Agreed.
Henri, is there a particular release you plan to "unship" this for? -t
On Tue, Apr 26, 2016 at 7:42 AM, Boris Zbarsky wrote:
> I think removing this is reasonable at this point
>
> -Boris
>
> ___
> dev-platform mailing list
> dev-platform@
This question is better suited to the dev-platform audience.
On 4/24/2016 1:50 PM, john smith wrote:
Hello,
Today I installed musl C x86-64 library next to GLIBC on Linux 86-64
system. It has been installed to /usr/lib/libc.so. I didn't expect
any problems with that, in fact all programs were
On 26/04/2016 14:01, James Graham wrote:
Based on a conversation yesterday, it seems that the features of |mach
try| are not well known. In particular it allows running only a subset
of tests in cases that you are doing an experimental push that you
expect to affect mainly one area of the code. F
Tru DAT
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
On the topic of debugging, it's worth noting that TLS 1.3 is going to be
quite a bit harder to debug from just network traces (without keying
material) than TLS 1.2 was because more of the traffic is encrypted.
-Ekr
On Tue, Apr 26, 2016 at 6:30 AM, Patrick McManus
wrote:
> I don't think the ca
I think removing this is reasonable at this point
-Boris
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
Agree with everything here. Right now (from my just-skimmed-the-bug
perspective) this seems like a "the sky is falling!" panic that has not
been justified, with a large amount of serious downside.
On Tue, Apr 26, 2016 at 6:30 AM, Patrick McManus
wrote:
> I don't think the case for making this ch
I think we need to have reasonable answers to Patrick's questions before
landing this patch. It's clear what we're losing, but unclear what we're
gaining.
/a
On 4/26/16 08:30, Patrick McManus wrote:
I don't think the case for making this change (even to release builds) has
been successfully m
is a strange feature from the dawn of HTML. It predates
proper functionality and provides a single search field that
maps to the URL query string in a way that differs from fields.
When Hixie specced the HTML parsing algorithm, he adopted the Trident
approach to , which is to treat the tag as a
+1 to Patrick's points. With HTTP/2 still in it's early stages a lot of CDN's
and server dev's use the keylogs to help debug their integrations. I know
several of them have been using the keylogs that WebPageTest automatically
pulls when it captures a tcpdump during testing.
__
On 26-04-16 14:54, Richard Barnes wrote:
> I guess there's some marginal security in turning off this capability
> in release browsers (though I have difficulty precisely articulating
> the threat model where it makes sense).
Chrome's position on this is relevant to that statement:
https://twitter
As someone who was high on the list of try server usage for two weeks
My problem was a test I tried to fix for both e10s and non-e10s, and it
timed out _sometimes_ on _some_ platforms even depending on debug/release
build. It was a whack-a-mole game by fiddling with the test and a complex
patch
I don't think the case for making this change (even to release builds) has
been successfully made yet and the ability to debug and iterate on the
quality of the application network stack is hurt by it.
The Key Log - in release builds - is part of the debugging strategy and is
used fairly commonly
On 15/04/16 16:47, Ryan VanderMeulen wrote:
I'm sure most of you have experienced the pain of long backlogs on Try
(Windows in particular). While we'd all love to have larger pools of test
machines (and our Ops people are actively working on improving that!), one
often-overlooked thing people can
On Tue, 26 Apr 2016, Martin Thomson wrote:
Maybe I'm unusual, but I just run debug builds when I want to investigate
this sort of thing.
That's easy for you and for all of us suitably involved and technically aware.
When ordinary users run into trouble and we ask them to wireshark their
traf
Keeping it in Nightly / Developer Edition seems like about the right
compromise to me. I guess there's some marginal security in turning off
this capability in release browsers (though I have difficulty precisely
articulating the threat model where it makes sense). But if we're going to
disable i
On Tue, Apr 26, 2016 at 6:08 PM, Jonas Sicking wrote:
> Limiting this to aurora builds might make the most sense here since
> that's what we're pushing as the build that developers should use.
I'm OK with that; that's why I asked here.
https://bugzilla.mozilla.org/show_bug.cgi?id=1188657
___
On Mon, Apr 25, 2016 at 11:17 PM, Martin Thomson wrote:
> On Tue, Apr 26, 2016 at 4:10 PM, Xidorn Quan wrote:
>> Could we probably restrict it to non-release builds (aurora and nightly)
>> rather than restrict them to debug builds only? Debug builds are harder to
>> get, and are slow.
>
> That wa
On Tue, Apr 26, 2016 at 2:56 PM, Mike Hommey wrote:
> On Tue, Apr 26, 2016 at 02:27:31PM +0800, Xidorn Quan wrote:
> > On Tue, Apr 26, 2016 at 2:17 PM, Martin Thomson wrote:
> >
> > > On Tue, Apr 26, 2016 at 4:10 PM, Xidorn Quan
> > > wrote:
> > > > Could we probably restrict it to non-release
On Tue, 26 Apr 2016, Mike Hommey wrote:
Very few developers will need to analyze traffic at a level requiring
SSLKEYLOGFILE.
Yes, but a larger share of users will do a network capture and submit to
Firefox developers on request when we debug network oriented problems. It is
almost standard p
26 matches
Mail list logo
