Another download option means double the build infrastructure load and double the QA effort.
Doing this halfheartedly is easy, while doing this properly is very hard. I don't think Mozilla would do this halfheartedly, properly is the only option. But again, anyone can fork that code and do it halfheartedly if they so choose.
Posted Mar 3, 2012 22:59 UTC (Sat) by dlang (✭ supporter ✭, #313)
[Link]
for a long time the 64 bit linux support was 'halfhearted' by your definition.
even if it's a halfhearted effort with just the builds, but without the in-house QA efforts, users can try it and report where it does and doesn't work.
as for the load on the build servers, I don't buy that as a limiting factor, builds are done frequently, but not continuously, and I've seen people talking about process changes for firefox development that would raise the frequency of builds by several orders of magnatude without any outcry about the massive new datacenter that would be needed to hold all the new build servers that this would require.
Mozilla announces HTML5-based phone
Posted Mar 3, 2012 23:04 UTC (Sat) by kripkenstein (subscriber, #43281)
[Link]
Yes, the 64-bit support is indeed halfhearted. But it is done as part of the process of making them formally supported, which isn't currently the case with multiprocess builds (there is no plan for making them supported).
I agree about the build servers, that's less of an issue, the main problem is QA effort which is already maxed out.
Mozilla announces HTML5-based phone
Posted Mar 4, 2012 1:05 UTC (Sun) by KaiRo (subscriber, #1987)
[Link]
For one thing, Firefox 64bit support is not halfhearted at all for Linux and Mac, but fully and officially supported (Windows is a different story).
For the other, split processes are still in the plans but postponed indefinitely while other ways of making the UI more responsive are being prioritized - Mozilla simply doesn't hve the manpower to do everything at once. The problem also isn't just add-ons but also that a lot of current Firefox UI has to be rewritten to communicate / react to website content asynchronously and indirectly, which it doesn't do right now.
Basically, it all comes down to being a lot of work, and a ton of QA and the manpower needed for this currently is being spent on things that are deemed higher priority like making the UI snappy to react in other ways. Volunteers doing work on achieving split processes sooner are of course welcome. It's not as simple as a switch though, there's a lot of work to be done before such a switch would leave even the current Firefox UI reasonably working.
Using split processes is much easier for something rewritten from scratch like the XUL (tablet) UI for mobile devices or - what this article is about actually - Boot to Gecko.