4 ms·

I disagree that there is no evidence in the thread that Gecko is too big. The "Gecko is too big" in the title is directly from the thread, started by a Mozilla

by farzul 15y ago

I disagree that there is no evidence in the thread that Gecko is too big. The "Gecko is too big" in the title is directly from the thread, started by a Mozilla developer. The evidence that development has stalled is the fact that the tree for landing code changes has closed. SPDY, recently announced here, has been, or is being considered for, removal to relieve code size.

holygoat 15y ago
(I'm a Mozillian.) These are slightly sensationalist ways of phrasing the following facts: * libxul hit linker limits on 32-bit Windows builds with profile guided optimization enabled, as it did a couple of years ago. PGO uses a lot of memory, but it's how we deliver on Windows, so it's important. * mozilla-central and mozilla-inbound were temporarily closed to avoid further build failures whilst the issue was explored. Other trees (try, services-central, etc. etc. etc.) remained open. * some recent large changes to libxul were backed out in order to relieve pressure on linking. * mozilla-central is now open for landings that aren't libxul-related, apart from those to trim it down. JavaScript and other landings continue unabated. See Bugzilla for the full scoop.
- farzul 15y ago
  So what you're saying is that Gecko (libxul) has gotten too big, and that development of libxul stuff (Gecko) has stalled until it has fixed. How is my title sensationalist? For those wondering, the bug where this is discussed is: https://bugzilla.mozilla.org/show_bug.cgi?id=709193 https://bugzilla.mozilla.org/show_bug.cgi?id=709193
  - khuey 15y ago
    To be clear, the only thing that's "stalled" is integrating large pieces of code into our nightly builds. People are certainly still working on developing their bug fixes/features/etc.
    - farzul 15y ago
      That's why I said "stalled" and not "halted" or "stopped". I'm surprised the discussion is around the wording of the title, half of which is your choice of wording, rather than the content. It's an interesting thing that a major open source development effort has hit a road bump in development, and the steps to solve it are interesting.

by farzul 15y ago

holygoat 15y ago

(I'm a Mozillian.) These are slightly sensationalist ways of phrasing the following facts: * libxul hit linker limits on 32-bit Windows builds with profile guided optimization enabled, as it did a couple of years ago. PGO uses a lot of memory, but it's how we deliver on Windows, so it's important. * mozilla-central and mozilla-inbound were temporarily closed to avoid further build failures whilst the issue was explored. Other trees (try, services-central, etc. etc. etc.) remained open. * some recent large changes to libxul were backed out in order to relieve pressure on linking. * mozilla-central is now open for landings that aren't libxul-related, apart from those to trim it down. JavaScript and other landings continue unabated. See Bugzilla for the full scoop.

farzul 15y ago
So what you're saying is that Gecko (libxul) has gotten too big, and that development of libxul stuff (Gecko) has stalled until it has fixed. How is my title sensationalist? For those wondering, the bug where this is discussed is: https://bugzilla.mozilla.org/show_bug.cgi?id=709193 https://bugzilla.mozilla.org/show_bug.cgi?id=709193
- khuey 15y ago
  To be clear, the only thing that's "stalled" is integrating large pieces of code into our nightly builds. People are certainly still working on developing their bug fixes/features/etc.
  - farzul 15y ago
    That's why I said "stalled" and not "halted" or "stopped". I'm surprised the discussion is around the wording of the title, half of which is your choice of wording, rather than the content. It's an interesting thing that a major open source development effort has hit a road bump in development, and the steps to solve it are interesting.