Re: On closing old bugs

On Tue, Dec 3, 2013 at 9:15 PM, Lawrence Mandel wrote: > > I would assert that if a bug hasn't been fixed in 10 years it probably isn't > important enough to spend time on now. I strongly disagree with this statement, and any follow-on implication that blanket-closing bugs based on age is accept

Re: On closing old bugs

On Tuesday 2013-12-03 21:15 -0800, Lawrence Mandel wrote: > I'm taking a stronger stance and suggesting that we should be able to wontfix > bugs that likely aren't worth anyone's time or attention. As a concrete > example, what is the value in keeping the following bugs open? > bug 3246 - Core::

Re: On closing old bugs

Opened that long ago, and haven't been touched for a long time? Or just opened that long ago? -- - Milan On 2013-12-04, at 14:15 , Lawrence Mandel wrote: > - Original Message - >> Lawrence Mandel writes: >> >>> - Original Message - On 27/11/13 07:36, Gabriele Svelto wrote

Re: On closing old bugs

- Original Message - > Lawrence Mandel writes: > > > - Original Message - > >> On 27/11/13 07:36, Gabriele Svelto wrote: > >> > I'm always tempted to close the former as duplicates of the > >> > actual fix and the latter as WONTFIX so that they won't show > >> > up on the following

Re: FYI: Nightly 28 uplift in 7 days

- Original Message - > This is a friendly reminder that the next channel merge date [1] is only > 7 days away! So don't forget to land those last minute bug fixes this > week. :) Also, you may want to hold destablizing or less important > changes until next week for Nightly 29. As Gavin me

Re: Exposing (mobile) device info via the user agent or HTTP headers

- Original Message - > On Friday, April 1, 2011 11:38:27 AM UTC-4, Benjamin Smedberg wrote: > > Discussion followup to bug 625238 > > . > > Hi, > > After reading through this discussion thread as well as the comments on the > bug report

Re: Valgrind-on-TBPL

Nick, this is great. Even just having the "PGO" tests passing under Valgrind means we can use V to diagnose intermittent failures in any suite. And maybe even to fuzz, although I'd like to see reftest and crashtest passing first. > 8) Must avoid patterns known to cause non deterministic failures

Re: Valgrind-on-TBPL

In the long run, it may be more efficient to use the clang "sanitizer" suite instead of Valgrind. It will need two runs (ASan+LSan+UBSan and MSan) but the total run time should be lower. http://clang.llvm.org/docs/UsersManual.html#controlling-code-generation > Valgrind can find the following kind

Valgrind-on-TBPL

Hi, I'm working on getting Valgrind (Linux64-only) runs visible on TBPL. https://bugzilla.mozilla.org/show_bug.cgi?id=valgrind-green is the tracking bug. This aim of this email is to (a) get answers to some questions I have, and (b) serve as a heads-up for people I will have to co-ordinate with.

Re: Deciding whether to change the number of unified sources

On 12/3/13, 2:48 PM, Mike Hommey wrote: >I tested unifying 99 files. On my not-super-fast MacBook Pro, I saw >no significant difference (up or down) in real time compared to 16 >files. This result is in line with Mike's results showing only small >improvements between 8, 12, and 16 files. Did yo

Re: Exposing (mobile) device info via the user agent or HTTP headers

On Friday, April 1, 2011 11:38:27 AM UTC-4, Benjamin Smedberg wrote: > Discussion followup to bug 625238 > . Hi, After reading through this discussion thread as well as the comments on the bug report page, I think that there is one reason to

Re: Deciding whether to change the number of unified sources

On Tue, Dec 03, 2013 at 01:30:39PM -0800, Jed Davis wrote: > On Tue, Dec 03, 2013 at 11:47:48AM -0800, L. David Baron wrote: > > On Tuesday 2013-12-03 10:18 -0800, Brian Smith wrote: > > > Also, I would be very interested in seeing "size of libxul.so" for > > > fully-optimized (including PGO, where

Re: Deciding whether to change the number of unified sources

On Tue, Dec 03, 2013 at 10:20:20AM -0800, Chris Peterson wrote: > On 12/3/13, 8:53 AM, Ted Mielczarek wrote: > >On 12/2/2013 11:39 PM, Mike Hommey wrote: > >>Current setup (16): > >> real11m7.986s > >> user63m48.075s > >> sys 3m24.677s > >> Size of the objdir: 3.4GiB > >> Size

Re: Deciding whether to change the number of unified sources

On 03/12/2013 22:30, Jed Davis wrote: At the risk of stating the obvious, localizing the size change should be a simple matter of `readelf -WS`. If we're seeing actual change in .text size by way of per-directory sort-of-LTO, then that would be interesting (and could be localized further with th

Re: Deciding whether to change the number of unified sources

On Tue, Dec 03, 2013 at 11:47:48AM -0800, L. David Baron wrote: > On Tuesday 2013-12-03 10:18 -0800, Brian Smith wrote: > > Also, I would be very interested in seeing "size of libxul.so" for > > fully-optimized (including PGO, where we normally do PGO) builds. Do > > unified builds help or hurt lib

Re: Deciding whether to change the number of unified sources

Here, stripping a non-opt debug linux 64bit libxul brings it down from 534 MB down to 117 MB. Benoit 2013/12/3 L. David Baron > On Tuesday 2013-12-03 10:18 -0800, Brian Smith wrote: > > Also, I would be very interested in seeing "size of libxul.so" for > > fully-optimized (including PGO, where

win64-rev2 cutover - Aurora and Beta timing

Status of the Windows build image upgrade from [1]: * mozilla-central and comm-central branches are building only on win64-rev2 * mozilla-inbound and b2g-inbound remain on a mixed rev1/rev2 pool to ensure an adequate number of build slaves to meet its high checkin load * 24 win64-rev1 build machin

Re: Deciding whether to change the number of unified sources

On Tuesday 2013-12-03 10:18 -0800, Brian Smith wrote: > Also, I would be very interested in seeing "size of libxul.so" for > fully-optimized (including PGO, where we normally do PGO) builds. Do > unified builds help or hurt libxul size for release builds? Do unified > builds help or hurt performanc

Re: Thinking about the merge with unified build

On 18:23, Mon, 02 Dec, Ehsan Akhgari wrote: As for identifying broken non-unified builds, can we configure one of our mozilla-inbound platforms to be non-unified (like 32-bit Linux Debug)? I think the answer to that question depends on how soon bug 942167 can be fixed. Chris, any ideas? We'

Re: Deciding whether to change the number of unified sources

On 12/3/2013, 2:08 PM, Benoit Jacob wrote: 2013/12/3 Chris Peterson On 12/3/13, 8:53 AM, Ted Mielczarek wrote: On 12/2/2013 11:39 PM, Mike Hommey wrote: Current setup (16): real11m7.986s user63m48.075s sys 3m24.677s Size of the objdir: 3.4GiB Size of libxul.

Re: Deciding whether to change the number of unified sources

On 12/3/2013, 1:18 PM, Brian Smith wrote: On Tue, Dec 3, 2013 at 8:53 AM, Ted Mielczarek wrote: On 12/2/2013 11:39 PM, Mike Hommey wrote: Current setup (16): real11m7.986s user63m48.075s sys 3m24.677s Size of the objdir: 3.4GiB Size of libxul.so: 455MB Just out of

Re: Deciding whether to change the number of unified sources

2013/12/3 Chris Peterson > On 12/3/13, 8:53 AM, Ted Mielczarek wrote: > >> On 12/2/2013 11:39 PM, Mike Hommey wrote: >> >>> Current setup (16): >>>real11m7.986s >>>user63m48.075s >>>sys 3m24.677s >>>Size of the objdir: 3.4GiB >>>Size of libxul.so: 455MB >>> >>> Ju

Re: Deciding whether to change the number of unified sources

On 12/3/13, 8:53 AM, Ted Mielczarek wrote: On 12/2/2013 11:39 PM, Mike Hommey wrote: Current setup (16): real11m7.986s user63m48.075s sys 3m24.677s Size of the objdir: 3.4GiB Size of libxul.so: 455MB Just out of curiosity, did you try with greater than 16? I tested

Re: Deciding whether to change the number of unified sources

On Tue, Dec 3, 2013 at 8:53 AM, Ted Mielczarek wrote: > On 12/2/2013 11:39 PM, Mike Hommey wrote: >> Current setup (16): >> real11m7.986s >> user63m48.075s >> sys 3m24.677s >> Size of the objdir: 3.4GiB >> Size of libxul.so: 455MB >> > Just out of curiosity, did you try with

Re: Deciding whether to change the number of unified sources

I would like to know the *effective* average number of original source files per unified source file, and see how it compares to the *requested* one (which you are adjusting here). Because many unified directories have a low number of source files, the effective number of sources per unified sourc

Re: Deciding whether to change the number of unified sources

On 12/2/2013 11:39 PM, Mike Hommey wrote: > Current setup (16): > real11m7.986s > user63m48.075s > sys 3m24.677s > Size of the objdir: 3.4GiB > Size of libxul.so: 455MB > Just out of curiosity, did you try with greater than 16? -Ted __

Re: Plug-in feature not available in the web platform. Alternatives?

Summarizing. 1) WebCrypto does not initially plan support for making end-user certificates available. 2) Our use case, currently implemented as a NPAPI plug-in, needs Mozilla to continue supporting NPAPI until WebCrypto makes end-user certficates available. I have a disturbing feeling. I hope tha

Re: Deciding whether to change the number of unified sources

I think that in order to fix the memory usage issues, we may need to adjust the number of unified sources at a per-directory level. For example, I would expect the compiler to consume more memory compiling more C++ feature heavy code such as the typical JS engine source code than the average G

Re: Deciding whether to change the number of unified sources

On 12/3/2013, 12:31 AM, Mike Hommey wrote: On Tue, Dec 03, 2013 at 12:18:46AM -0500, Boris Zbarsky wrote: On 12/2/13 11:39 PM, Mike Hommey wrote: 1. By the way, those type of bugs that show up at different number of unified sources are existing type of problems waiting to arise when we add sour