Re: PSA: Cancel your old Try pushes

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

Re: Intent to (sort of) unship SSLKEYLOGFILE logging

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.

Re: Intent to remove:

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

Re: Clarifications needed to 'Intent to ship' process

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

Re: Automation / Firefox 48 switched to Visual Studio 2015 Update 2

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 >

Re: Clarifications needed to 'Intent to ship' process

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

Re: Clarifications needed to 'Intent to ship' process

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?)

Re: Intent to (sort of) unship SSLKEYLOGFILE logging

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

Re: Intent to (sort of) unship SSLKEYLOGFILE logging

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

Re: Intent to (sort of) unship SSLKEYLOGFILE logging

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

Re: PSA: Cancel your old Try pushes

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

Re: Intent to (sort of) unship SSLKEYLOGFILE logging

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:

Re: PSA: Cancel your old Try pushes

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

Re: Intent to (sort of) unship SSLKEYLOGFILE logging

+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.

Re: Intent to remove:

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

Intent to remove:

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

Re: Intent to (sort of) unship SSLKEYLOGFILE logging

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

Re: Intent to (sort of) unship SSLKEYLOGFILE logging

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 was suggested, but we decided against it in

Re: Intent to (sort of) unship SSLKEYLOGFILE logging

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 builds (aurora and

Re: Intent to (sort of) unship SSLKEYLOGFILE logging

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:

Re: How is libc shared object chosen in libxul?

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

Re: Intent to (sort of) unship SSLKEYLOGFILE logging

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 > > >

Re: Intent to (sort of) unship SSLKEYLOGFILE logging

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

Re: Intent to (sort of) unship SSLKEYLOGFILE logging

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

Re: PSA: Cancel your old Try pushes

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.

Re: Proposed W3C Charter: Timed Text Working Group

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