Weekly Edition
Return to the Development pageRecent Features
| |||||||||||||
Mozilla dumps Firefox 3.7 from schedule, changes dev process (ComputerWorld)
ComputerWorld reports on an interview with Mozilla's Mike Beltzner about changes in how Mozilla plans to deliver new features in Firefox.
"Rather than add features to Firefox only in once- or twice-a-year upgrades, Mozilla will quietly insert some functionality via its regular security updates, which appear every four to six weeks, said Mike Beltzner, director of Firefox, in an interview Thursday.
[...]
That means Firefox 3.7, which was slated for a second quarter release, has been dropped from the development schedule, said Beltzner. The next version of the open-source browser after the almost-ready Firefox 3.6 will be an as-yet-unnamed update at the end of this year or in early 2011."
(Log in to post comments)
Mozilla dumps Firefox 3.7 from schedule, changes dev process (ComputerWorld) Posted Jan 17, 2010 2:43 UTC (Sun) by BenHutchings (subscriber, #37955) [Link]
Bundling feature changes with security fixes is just the way to scare users away from accepting automatic security updates. It's really not a responsible release policy.
Mozilla dumps Firefox 3.7 from schedule, changes dev process (ComputerWorld) Posted Jan 17, 2010 3:02 UTC (Sun) by jmm82 (guest, #59425) [Link]
I bet this is due to Chrome's method of updating which always pushes the
latest and greatest no questions asked. If I understood correctly Chrome does not even prompt people when they push updates. You got to keep up with the Johnsons's.
Mozilla dumps Firefox 3.7 from schedule, changes dev process (ComputerWorld) Posted Jan 17, 2010 3:19 UTC (Sun) by stumbles (guest, #8796) [Link] I don't want to run any piece of software that I cannot disable automatic updates.
Mozilla dumps Firefox 3.7 from schedule, changes dev process (ComputerWorld) Posted Jan 17, 2010 3:41 UTC (Sun) by intgr (subscriber, #39733) [Link]
You can disable updates, but by default - on Windows at least - it updates
automatically without even asking.
Mozilla dumps Firefox 3.7 from schedule, changes dev process (ComputerWorld) Posted Jan 17, 2010 3:54 UTC (Sun) by SEMW (guest, #52697) [Link]
As intgr notes, jmm82 was talking about the default settings on Windows. But since you're reading lwn, it's a fair bet that you're on Linux, in which case chrome/chromium updates are done in the normal way: through your system's package manager, via a Google repository that is added when you install chrome.
So whether updates happen at all, whether they are automatic or not, and whether you get prompted with the changelogs before the update happens are matters between you and your package manager; Google has little to do with it.
Mozilla dumps Firefox 3.7 from schedule, changes dev process (ComputerWorld) Posted Jan 17, 2010 6:15 UTC (Sun) by tzafrir (subscriber, #11501) [Link]
Having a cron job to add (and re-add) your APT source is not really "the standard way" in Linux.
Mozilla dumps Firefox 3.7 from schedule, changes dev process (ComputerWorld) Posted Jan 17, 2010 9:51 UTC (Sun) by drag (subscriber, #31333) [Link]
I don't get it. Why would I want a cron job to edit my sources for?
I don't understand why Chrome would be a special case vs anything else added
Mozilla dumps Firefox 3.7 from schedule, changes dev process (ComputerWorld) Posted Jan 18, 2010 14:57 UTC (Mon) by SEMW (guest, #52697) [Link] > I don't understand why Chrome would be a special case vs anything else added via apt-get.From Google's point of view: because people who download Chrome from their website by definition *aren't* adding it via "apt-get install chrome" (that then gets it from the google repository); they're installing a static deb on a system that doesn't yet have the repo. So from Google's point of view, adding their repository as part of the post-install script, so that Chrome will be updated as part of general system updates, is a perfectly sensible thing to do. You have to admit, it's friendlier to new users than publishing steps for how to manually add the repo. And it (having chrome update as part of system updates) is what the vast majority of people will want. And if you don't want it, there is a prominent notice at the bottom of the Chrome download page that explains the above and tells you what to do if you don't want the repo added. (The issue where, if you manually delete the repo .list file, it would get readded at some point was a bug that has now been fixed. They're still being stubborn about using cron and calling that from the post-install script, rather than doing it in the script directly, apparently in order to keep it there during version upgrades (during which Ubuntu disables third party repositories); but if you delete the .list file manually, it stays deleted. (Personally, I'm using the Ubuntu-specific chromium-browser build rather than the Google build, but that's just because that was all there was when I installed it)).
Mozilla dumps Firefox 3.7 from schedule, changes dev process (ComputerWorld) Posted Jan 17, 2010 11:19 UTC (Sun) by cortana (subscriber, #24596) [Link]
No problem. Firefox will only auto-update if you run it as an administrator, which you really should not be doing! :)
Mozilla dumps Firefox 3.7 from schedule, changes dev process (ComputerWorld) Posted Jan 17, 2010 5:23 UTC (Sun) by Kit (guest, #55925) [Link]
Which is a very reasonable default. Security fixes should automatically be pushed out to the users without them having to intervene. I know people that never bother to let Firefox update, simply because it annoys them and they see no reason why.
The people that don't want automatic updates, and have a technically sound reason, are the ones that can figure out how to disable the auto updates.
Mozilla dumps Firefox 3.7 from schedule, changes dev process (ComputerWorld) Posted Jan 17, 2010 6:17 UTC (Sun) by tzafrir (subscriber, #11501) [Link]
Or until an upgrade breaks things, and then you'll start seeing "disable automatic upgrades" as a common wisdom.
Mozilla dumps Firefox 3.7 from schedule, changes dev process (ComputerWorld) Posted Jan 17, 2010 6:31 UTC (Sun) by jmm82 (guest, #59425) [Link]
yeah these are the same people still running Netscape navigator. Boy is it
stable...too bad it can no longer render half the web{sarcasm}
Mozilla dumps Firefox 3.7 from schedule, changes dev process (ComputerWorld) Posted Jan 17, 2010 15:10 UTC (Sun) by Kit (guest, #55925) [Link]
I'd rather have upgrade-risk than people sitting on an old, insecure version of the browser that'll just allow anything through, making the Internet even more screwed up.
And that isn't just a problem on Windows, an insecure browser on Linux will be just as much of a problem for the average user and the Internet as a whole as one on Windows.
Mozilla dumps Firefox 3.7 from schedule, changes dev process (ComputerWorld) Posted Feb 2, 2010 0:44 UTC (Tue) by jschrod (subscriber, #1646) [Link]
The issues is not that security updates are pushed automatically, the issue is that *FEATURE UPDATES* are pushed automatically.
Most folks consider the first good to be on by default; the second not. That's because the risk-benefit analysis of the 1st is good for both Google/Mozilla and users (trading a bit of stability for lots of security and better PR), while the same analysis for the 2nd gives questionable results for many users (trading stability, and often a lot of it, for enhancements that one might want or might not want and better PR).
Nightmare for stable installations. Posted Jan 17, 2010 5:23 UTC (Sun) by bignose (subscriber, #40) [Link]
Great. This is pretty much a vindication of Debian's position on patches to Firefox.
People administrating a long-term stable operating environment want to be able to apply security fixes and *nothing but* security fixes, during the lifetime of that environment. That needs to continue unless and until they choose, on their own schedule, to migrate to a newer version with additional features.
That's what Debian promises with its 'stable' suite: no new features, the only changes that get in are for crucial bug fixes or security fixes. So, once the Firefox code base is released in Debian 'stable', it gets *no* new features, and receives whatever high-priority bug fixes are necessary, implemented as minimal changes to the code over the lifetime of any particular iteration of Debian 'stable'.
Yet Mozilla Corp. insists on a trademark policy that is completely opposed to that. No-one is free to release a patched Firefox and still call it Firefox, unless they pass the patches through Mozilla's approval process -- a severe bottleneck when one is trying to get a security fix out quickly.
So the only way to keep a stable installation of Firefox up-to-date with security fixes, released as soon as possible, and *without* any additional features (hence "stable"), is to get something that's not allowed to be called Firefox. Hence Iceweasel http://lwn.net/Articles/118268/.
Hopefully this new anti-security Mozilla release policy of "no, you can't opt to get only the security fixes" will drive more operating systems to take the Iceweasel approach, and pressure Mozilla to change their trademark policy for the better.
Nightmare for stable installations. Posted Jan 17, 2010 5:36 UTC (Sun) by jmm82 (guest, #59425) [Link]
Fine so Debian can do the same thing they do with their kernel to Firefox.
Which is cherrypick bug fixes off Firefox and backport them to their system.
Nightmare for stable installations. Posted Jan 17, 2010 5:42 UTC (Sun) by jmm82 (guest, #59425) [Link]
ok I misread your comment the first time... apparently they cannot just
cherrypick what they want and call it Firefox is what you are saying.
Nightmare for stable installations. Posted Jan 17, 2010 7:28 UTC (Sun) by wblew (subscriber, #39088) [Link]
Which they have already chosen to call Iceweasel and thus avoid the Firefox
trademark entirely. Which mean *they* and not *Mozilla* are responsible for the support of Iceweasel. As near as I can tell, Mozilla is reluctant to pay for others' choices, hence their patch review policy.
The beauty of open source is: if you don't like it, do it yourself. But then
Nightmare for stable installations. Posted Jan 17, 2010 12:18 UTC (Sun) by dbruce (subscriber, #57948) [Link]
Mozilla won't let distros patch Firefox at all and still let it be called Firefox, unless the patch is sign off by Mozilla.
Although I love Firefox and the Mozilla Foundation's efforts, this trademark policy is exceedingly unhelpful for (GNU)/Linux. Basically all OSS software gets patched when packaged for inclusion in a distribution, and no one else AFAIK requires that the program be called something different.
I think Firefox is different because it is the one prominent OSS program that clearly has Windows as its primary platform. The Windows software world has a lot more unscrupulous actors that might put out modified Firefox builds that do bad things, so I think Mozilla is being a lot more defensive.
It would be nice if there were a way to let innocuously-patched builds (like what Debian would do) carry the Firefox trademark, but still prevent "evil" modifications that e.g. bundle in malware from being called Firefox. I guess that is why Mozilla insists on signing off on patches.
Allowing free choice inevitably brings in potential for both good and bad.
Nightmare for stable installations. Posted Jan 17, 2010 17:12 UTC (Sun) by jwarnica (subscriber, #27492) [Link]
Well, the grand irony of the whole situation is that Debian also has a trademark policy. Now, the Debian policy is something along the lines of "you can say _based_ on Debian"; Mozilla policy is obviously different on this point.
I don't agree with your premise that "basically all" software is patched by distros; at least beyond build-time options, I don't think that even most software is patched by distros. I think its a bad policy to do this, unless absolutely necessary; distro developers should be prepared to spend as much effort getting their patches applied upstreem as they do actually writing them.
Firefox is unique because it is a prominent OSS program which has multiple and varied platforms as its primary platform. Firefox on MacOS X should be the same experience as on Linux, and the same as on Windows. This consistency is one of the goals of Firefox. Another goal of Firefox is the development of a surrounding ecosystem, from addons, to devmo, to the very return of competition and innovation in the browser space.
Mozilla considers the branding, consistency, and stability of Firefox to be important. They recognize that the web is a fast moving and changing place, and their general-purpose browser has a development, and update policy to match.
One of the other defining qualities of Firefox is that it has a rapid development time-line, and updates itself frequently, keeping itself current with security and feature packs.
Debian (stable) considers stability to be the most important thing.
Clearly "stability" and "evolving" are conflicting goals.
Debian wants to ship a dead browser. Debian fanboys are pissed that Mozilla isn't falling over themselves to help Debain in this goal.
It isn't just about the code. Firefox has an update mechanistic; while maybe only an #ifdef away, something that doesn't update itself isn't Firefox.
What you might call an innocuous patch to increase stability I might call a patch which also violates the design goal of "Firefox, the product" and "Firefox, the project".
In short: Debian wants to use a popular product while disabling all the things which make it popular.
Nightmare for stable installations. Posted Jan 17, 2010 19:55 UTC (Sun) by vaib (guest, #48292) [Link]
Perhaps Debian is doing same thing with every of those 15-20k packages and
none of them is bothered. If every of those package owner starts to show ire like mozilla had shown where you would be. Forget any distro could even exist with that kind attitude. Well every one has rights over own software so mozilla says to Debian, "keeps your hands off". Debian says "Okk". Matter is over. I really wonder why you had to be so agitated and blame Deian. They were just following the process as they do with 20k other packages. And they fully comply mozilla's request. I would hope that you can cut some slack for Debian.
Nightmare for stable installations. Posted Jan 17, 2010 21:56 UTC (Sun) by jwarnica (subscriber, #27492) [Link]
While I do think the world would be a better place if (all) distros moved closer along the continuum towards "patch upstream, configurations here", away from "patch first and don't so much as tell people", that really isn't on point here. Its not 1994 and 90% of ones distro was random shit from sunsite.unc.edu, which was last updated in 1987 and with maintainers having UUNET email addresses. It is possible to submit a patch which is both good for a specific distro and good in general. Its possible to refactor a distro specific patch to be configuration, or just generally applicable. And its possible to have patches which are distro specific and anti-goals of upstream. At this point I really don' know or care the technical details of where the Debian patches fit on this scale. Its really irrelevant.
My issue isn't with Debian taking the code part of Firefox, changing it, and then branding it as something else.
Debian has a design goal; Mozilla has a design goal Both have individually solved their respective and conflicting goals. The organizations, as far as I understand it, have agreed to disagree.
My issue is the Debian fanboys who insist that Debians goal is a) an inherently more important goal and/or b) that Mozilla should somehow change their design goals to match Debians.
Nightmare for stable installations. Posted Jan 17, 2010 22:05 UTC (Sun) by jordanb (guest, #45668) [Link]
The thing is, Debian tried for a long time to work with the Mozilla Corporation to meet its own design goals while trying to maintain permission to use the Firefox trademark.
Over time, the Mozilla Corporation grew more and more belligerent, until their position came down to an ultimatum: violate the Debian policy and follow MozCo's plan or quit using the trademark.
Given that situation, changing the name was the only choice Debian had left.
Nightmare for stable installations. Posted Jan 17, 2010 22:23 UTC (Sun) by jwarnica (subscriber, #27492) [Link]
And Debian, standing by their policy as they should, made a decision. MozCorp, standing by their policy, also made a decision.
Both organizations stuck by their policies. Fine. Lets move on. Oh, but we can't; any story involving MozCorp and/or Firefox somehow causes people to bring up how Debian manages the Firefox codebase better then Mozilla does. Fuck off, really. Let it go.
I'm not annoyed with Debian not changing their policy to allow for exceptions in leaf, end-user, nothing-depends-on-me, and/or healthy and well managed packages. And I'm not annoyed with MozCorp for what might be a hyperactive desire for brand protection.
I'm annoyed with Debian fanboys who look at the situation and say: MozCorp is being mean to us, our policy is more important, they should change.
Nightmare for stable installations. Posted Jan 17, 2010 23:01 UTC (Sun) by foom (subscriber, #14868) [Link]
I agree with everything you said, except one thing: the implication that Mozilla Firefox is a "leaf,
end-user, nothing-depends-on-me" package.
Most of what firefox is is actually the rendering engine and UI libraries, packaged separately
Nightmare for stable installations. Posted Jan 17, 2010 23:16 UTC (Sun) by jwarnica (subscriber, #27492) [Link]
Ah. Is there actually that split? xulrunner.deb being ~ 10Mb, and iceweasel.deb being 100K? Or is there xulrunner and also iceweasel, both ~ 10MB (or whatever?). Has iceweasel totally broken off from Fx, and is running on xulrunner?
I don't think that the stock Firefox runs on XULRunner ATM, even a "private" one. Source code wise, sure. Last I checked, this was a FF 4.x project.
Yeah, that separation is a slow and painful one; I remember have to track down a very specific 5 year old binary trying to get a browser working inside Eclipse . MozCorp should be producing a high-quality embeddable xulruner; and really blessing it as the-thing-to-link-against. I'm not sure how far along this is.
But that is a whole other pile of crap to debate. And I think that it boils down to "hasn't happened yet" rather then "that would be an anti-goal".
Nightmare for stable installations. Posted Jan 18, 2010 0:17 UTC (Mon) by foom (subscriber, #14868) [Link]
> Ah. Is there actually that split?
Yes. Debian had to do that in order to efficiently patch security vulnerabilities: they only want to
See e.g. http://packages.debian.org/lenny/iceweasel
You can check out the dependencies list (depends on xulrunner-1.9), and the changelog for
> I don't think that the stock Firefox runs on XULRunner ATM, even a "private" one.
XULRunner's webpage disagrees with you:
""Firefox 3 and later ships with a private XULRunner package, which can run any compatible
Nightmare for stable installations. Posted Jan 18, 2010 0:41 UTC (Mon) by nix (subscriber, #2304) [Link]
And it's not as if this split requires radical changes to firefox's
upstream, either, or indeed any at all. FF is *designed* this way (well, has been hacked into working this way) by upstream.
Nightmare for stable installations. Posted Jan 21, 2010 14:51 UTC (Thu) by gerv (subscriber, #3376) [Link] MozCorp should be producing a high-quality embeddable xulruner; and really blessing it as the-thing-to-link-against. I'm not sure how far along this is. In general, I agree with your line of argument, but it can be used against your assertion here. The Firefox-shipping bit of Mozilla has declared a "high-quality embeddable XULRunner" to be a non-goal for them. (Other community members are, of course, free to make it their goal. And some do.) This is just another case of different organizations solving different engineering challenges different ways. Linux distros don't want to duplicate the XULRunner code in each package which uses Mozilla as a base; Mozilla doesn't want to spend time perfecting an embeddable stable-API XULRunner when they could be making Firefox rock more. So by saying Mozilla "should" do that, aren't you doing what you suggested Debian fanboys were doing - saying that Mozilla's goals should change to match yours? Gerv
Nightmare for stable installations. Posted Jan 17, 2010 23:16 UTC (Sun) by jordanb (guest, #45668) [Link]
MozCo's policy *did* change though, over time, to become more and more hostile towards Debian. For years, MozCo and Debian had an agreement that was aware of both Debian's needs and MozCo's trademark policy.
The problem that caused the name change was that MozCo revoked that agreement.
It was MozCo's *changing* terms that annoyed people on the Debian side of the equation.
From Wikipedia:
http://en.wikipedia.org/wiki/Mozilla_Corporation_software...
Nightmare for stable installations. Posted Jan 17, 2010 23:28 UTC (Sun) by jwarnica (subscriber, #27492) [Link]
Maybe I overstepped with the use of "policy". Consider it changed to "project vision". How is a shift in policy which is consistent with the project vision, and the removal of Debian exceptions better or worse, anyway? And aren't Debian exceptions a violation of the DFSG, anyway?
Anyway. Thanks for reaffirming my issue. Debian wasn't targeted. MozCorp made a decision based on what was best for them, and Debian fanboys see this as being evil because everyone should be tripping over themselves to conform to the DFSG. Paranoid much?
Nightmare for stable installations. Posted Jan 18, 2010 13:01 UTC (Mon) by nix (subscriber, #2304) [Link]
Debian needs the ability to rapidly patch software they ship to avoid security vulnerabilities. They also need the ability to patch *only* security vulnerabilities, without making other changes that may lead to regressions. This is not a surprising nor a rare requirement (all the long-term support / enterprise distros will have precisely the same needs), and that Mozilla can't accommodate it without forcing a change of program name (and *directory* names!) reflects badly on Mozilla, not on Debian. It's not about 'DFSG fanboys'. It's about stability and security.
Nightmare for stable installations. Posted Jan 21, 2010 16:58 UTC (Thu) by gerv (subscriber, #3376) [Link]
It's a reflection of the nature of the web, and the trade-offs you have to make when shipping complex software to 300 million people with a small engineering organization. Having the web still be an open platform in 100 years is the goal. That means you have to compete technologically in a very challenging environment (who else has to compete with all three of Google, Microsoft and Apple?). Effort goes into innovation, not 5-year stable branches. People who want those have to maintain them themselves. And Debian does. Which is fine.
It would be great if Mozilla could maintain six branches at once, with varying levels of stability and feature focusses. But they can't. And they can't give Debian the trademark rights if Debian insists on being able to pass them on to anyone else (and that seems to be how the DFSG is being interpreted) - it would be equivalent to giving up the trademark altogether.
Nightmare for stable installations. Posted Jan 22, 2010 16:11 UTC (Fri) by nix (subscriber, #2304) [Link]
Well, yes, if Debian was trading on the name of Firefox. Which it isn't.
The passing-on-to-others might dictate a change of program name, but changing the name of the /usr/lib/firefox-* directory is surely not called for. Nobody would ever say 'ooh, look, /usr/lib/firefox* is there, therefore this must be the Actual Official Firefox': I have about 120 directories under my /usr/lib, and less than half are named after programs.
Nightmare for stable installations. Posted Jan 22, 2010 17:51 UTC (Fri) by gerv (subscriber, #3376) [Link]
The discussions were not about the name of the /usr/lib/firefox-* directory (although Debian may have elected to change that when they switched names) but about using the logo and branding the product "Firefox" in itself and in menus etc. Doing that is certainly "trading on the name of Firefox" and therefore an activity subject to trademark law.
Nightmare for stable installations. Posted Jan 19, 2010 17:52 UTC (Tue) by pboddie (subscriber, #50784) [Link] Oh, but we can't; any story involving MozCorp and/or Firefox somehow causes people to bring up how Debian manages the Firefox codebase better then Mozilla does. If it means not having applications which all want to dial home all the time, Windows-style, then there is something to be said for the distribution approach of patching undesirable behaviour in upstream software. Fuck off, really. Let it go. Does this attitude work out for you in public, face-to-face interactions, too?
Nightmare for stable installations. Posted Jan 20, 2010 14:06 UTC (Wed) by nhippi (subscriber, #34640) [Link]
> I'm not annoyed with Debian not changing their policy to allow for
> exceptions in leaf, end-user, nothing-depends-on-me, and/or healthy > and well managed packages.
Others mentioned already the xulrunner issue, but there is also all the
That said, real "leaf, end-user, nothing-depends-on-me" packages are not
Note that Debian doesn't really have that coherent policy (on dealing with
Nightmare for stable installations. Posted Jan 18, 2010 10:52 UTC (Mon) by nye (guest, #51576) [Link]
>Firefox on MacOS X should be the same experience as on Linux, and the same as on Windows. This consistency is one of the goals of Firefox
This is somewhat deviating from the topic, but I don't think that's true at all.
Firefox on Linux has numerous aggravating changes made, such as reversing the order of most of the buttons (after a crash, there's an option to either restore the session or to start anew; this is where the button reversal hurts the most), moving around menu entries, enabling/disabling certain options by default, and changing some of the shortcut keys.
As a result it's extremely annoying switching back and forth between Firefox on Windows and Firefox on Linux.
Nightmare for stable installations. Posted Jan 20, 2010 19:10 UTC (Wed) by roc (subscriber, #30627) [Link]
The button order is switched to be consistent with GNOME.
In Firefox "Consistent UI across platforms" is lower priority than "consistent UI with other apps on the platform". This is what most of the GTK/Linux community seem to want. Otherwise we wouldn't make the extra effort...
Nightmare for stable installations. Posted Jan 19, 2010 6:41 UTC (Tue) by dbruce (subscriber, #57948) [Link]
"I don't agree with your premise that "basically all" software is patched by distros; at least beyond build-time options, I don't think that even most software is patched by distros."
OK, "basically all software" is an overstatement. But it is certainly true that "basically all" distros incorporate patches into packages when needed to get them to work in their environment. Both RPM and Deb packages support patching, as do other systems like FreeBSD Port Collection and MacPorts.
It is great when an upstream program doesn't need any patches at all, and also great if the program has good build-time configure options. Still, source patching is definitely part of the packager's repertoire.
The main point is that in the open source world, no one else screams "fork" when patching like this is done. Normally an open source program can be modified without having to call it by a different name. Imagine the chaos that would exist if all projects took the stance that even a slight downstream modification must be called be a different name. It just goes against the core principals that interest people in Free/Open software in the first place.
Also, it isn't helpful to throw around terms like "Debian fanboys".
Nightmare for stable installations. Posted Jan 18, 2010 8:41 UTC (Mon) by hensema (guest, #980) [Link]
> People administrating a long-term stable operating environment want to be able to apply security fixes and *nothing but* security fixes, during the lifetime of that environment. That needs to continue unless and until they choose, on their own schedule, to migrate to a newer version with additional features.
That's perfectly fine for standalone boxes. But most of us have to deal with the ever changing world. What works today may not work tomorrow. This is especially true for applications dealing with the volatile content of the web. Virusscanners, spamfilters, web browsers, twitter clients, and to a lesser extend, mail clients.
Of course a server environment can be very stable without any new features for years. But a web browser is client software. It needs to adapt to a changing world.
Trying to force a browser into stability results in MSIE6. Really.
Nightmare for stable installations. Posted Jan 18, 2010 10:46 UTC (Mon) by mpr22 (subscriber, #60784) [Link]
Conversely, people shouldn't have to go without their security fixes just because they don't want their browser's attack surface increased by the addition of support for yet another flavour of ill-considered and haphzardly designed web bling.
Nightmare for stable installations. Posted Jan 19, 2010 21:56 UTC (Tue) by rqosa (subscriber, #24136) [Link] > is to get something that's not allowed to be called Firefox. Hence Iceweasel http://lwn.net/Articles/118268/ I really don't understand why Debian persists in using their "Iceweasel" branding when upstream has for a long time now included the branding switch. Compiling with the branding flag off will cause the browser's name to be the codename of the release series (currently "Shiretoko") and the icon to be a globe without the fox. (This is how Arch Linux builds their Firefox packages.) > and pressure Mozilla to change their trademark policy for the better. Why does it matter what the trademark policy is, when it's a simple matter for distributors to just not use the trademark?
Nightmare for stable installations. Posted Jan 20, 2010 6:23 UTC (Wed) by jspaleta (subscriber, #50639) [Link]
how does Arch handle the package name and package versioning? Does the packagename match the release codename instead of just calling the package firefox? How are release bumps across codenames handled?
-jef
Nightmare for stable installations. Posted Jan 20, 2010 14:03 UTC (Wed) by rqosa (subscriber, #24136) [Link] The package is just called "firefox". The version is the upstream version, with an extra number appended onto it. Nothing special is done when the codename changes. $ pacman -Si firefox Repository : extra Name : firefox Version : 3.5.7-1 URL : http://www.mozilla.org/projects/firefox Licenses : MPL GPL LGPL Groups : None Provides : None Depends On : xulrunner=1.9.1.7 desktop-file-utils Optional Deps : None Conflicts With : None Replaces : firefox3 Download Size : 1029.44 K Installed Size : 3668.00 K Packager : Biru Ionut <ionut@archlinux.ro> Architecture : x86_64 Build Date : Tue 05 Jan 2010 01:24:10 PM PST MD5 Sum : 617d6e5ed279f11bbb8c24a7a7dc9b76 Description : Standalone web browser from mozilla.org
Nightmare for stable installations. Posted Jan 20, 2010 10:01 UTC (Wed) by mpr22 (subscriber, #60784) [Link] Having established their own branding for their web browser based on the Mozilla Firefox project, why would Debian make everyone go through another package name-change by discarding it? (To say nothing of the suboptimality of having to make name changes when switching from 2.0 to 3.0, 3.0 to 3.5, 3.5 to 3.6, etc.)
Mozilla dumps Firefox 3.7 from schedule, changes dev process (ComputerWorld) Posted Jan 17, 2010 5:29 UTC (Sun) by jmm82 (guest, #59425) [Link]
I am running Chromium off the ppa repo in ubuntu, so I expect unstable and
yes my updates come through the package manager.
My comment about Chrome auto updates was based on a statement made my a
Regardless of if the updates included a prompt, Google appears to have been
Everyone will scrutinize Firefox for this, but I see it as them trying to
Mozilla dumps Firefox 3.7 from schedule, changes dev process (ComputerWorld) Posted Jan 17, 2010 5:32 UTC (Sun) by louie (subscriber, #3285) [Link] Probably worth reading Beltzner's own blog post (which begins with 'the rumours of Firefox 3.7's demise have been greatly exagerrated') for more context.
Mozilla not dumping Firefox 3.7 (ComputerWorld is full of it) Posted Jan 18, 2010 19:13 UTC (Mon) by The_Barbarian (subscriber, #48152) [Link]
I can't believe LWN actually ran this. I wasn't surprised to see it on Slashdot - running suspicious, inadequately sourced articles is par for the course with them, but at LWN I expect better.
Mozilla not dumping Firefox 3.7 (ComputerWorld is full of it) Posted Feb 2, 2010 1:00 UTC (Tue) by jschrod (subscriber, #1646) [Link]
I read the blog.
It basically says that new features should be rolled out as updates and not as new versions. Which is what LWN citation's of ComputerWorld essentially tells. It calls that "agile". Usage of that corporate-speak term was alone enough to make me shudder about that new direction.
ikm's comment below about "you wake up and suddenly have an awesome bar" is exactly on the spot. (Yes, I've read that user-visible changes should not be done this way, and I've also read the later examples that are user-visible.) In the end, this new direction fits quite nicely the "we know better than you and thus you must trust us" approach of many Firefox developers.
Mozilla not dumping Firefox 3.7 (ComputerWorld is full of it) Posted Feb 2, 2010 1:26 UTC (Tue) by dlang (✭ supporter ✭, #313) [Link]
this is the approach that the kernel team has been using for several years now. In spite of 'experts' proclaiming the end of the world every few months, it has worked out well, new features included.
the reason why this is the new fad in software development is that (if done properly), it works quite well, for users as well as for developers.
Mozilla not dumping Firefox 3.7 (ComputerWorld is full of it) Posted Feb 2, 2010 1:54 UTC (Tue) by jschrod (subscriber, #1646) [Link]
Well, luckily *my* Linux kernel has no fully automatic update feature that installs new features without even asking me before installing a new kernel version. I still have to do that myself. Besides, my kernel updates are only security updates, to get new features I typically have to do a distribution upgrade. Oh yes, and I consider myself a typical Linux user, though not a kernel developer.
Even if one doesn't look a the pushed-noninteractive-automatic feature update problem, your argument doesn't hold water:
1) Most people don't use Linus' kernel, they use their distribution's kernel. And with the exception of rawhide or similar highly-experimental repositories, most distributions are very conservative in changing their kernel. I don't get a new kernel every day; my kernel typically gets only patches with security updates.
2) Those who run the latest RC from kernel.org are typically developers, and install the new kernel to test out the new features. I.e., the install it by a conscious [sp?] act to *get the new features*. Comparing developers and testers of new kernel features with users of an app like Firefox is like comparing apples to oranges. Here the equivalent would be Firefox's nightly build, which exists and is good to have, but has nothing to do with my argument concerning released versions.
3) Even disregarding this, there *are* kernel.org releases every 4 months or so, just like Firefox releases up to now. According to the blog, Firefox folks want to have a *continuous* ``agile'' feature update policy for the time between releases, targeting their end users. This is not something that I have heard the kernel folks proposing. Quite to the contrary, with the explicit "merge window and stabilization phases" model they are very much an example on a release-based distribution for our end-users model and not an example of a "continuous upgrade by automated push-updates" model.
Mozilla not dumping Firefox 3.7 (ComputerWorld is full of it) Posted Feb 2, 2010 2:13 UTC (Tue) by dlang (✭ supporter ✭, #313) [Link]
what distro do you run? I'll bet it has the option to do the fully automatic kernel upgrade for you.
overall the difference in in the defaults, not in the capabilities.
the 'Agile' development model is the merge/develop window, then stabilize, then release, repeat on a fairly short time window, extending the same codebase out.
mozilla has been making a release every few months, but most of those releases are bugfix only releases, releases with major work in them are much further apart.
This results in some bugs being marked as 'fixed' when they have only been fixed in the next release codebase that won't see the light of day for multiple years. With the agile approach, any fix will go into the next merge window and be in the release after that (unless a problem is found and it needs to be reverted)
Mozilla not dumping Firefox 3.7 (ComputerWorld is full of it) Posted Feb 2, 2010 10:37 UTC (Tue) by jschrod (subscriber, #1646) [Link]
> what distro do you run? I'll bet it has the option to do the fully
> automatic kernel upgrade for you.
You don't seem to understand me. It's not about automatic upgrades, it's about pushing *major features* in those upgrades without forwarning. Look at the blog's examples, the kernel equivalent would be delivery of a new scheduling subsystem, not inclusion of a new driver.
And all the distributions that I run (OpenSUSE, SLES, RHEL, Debian stable, Debian testing, and Ubuntu) don't do this.
I also differ with your assessment of the agile development process of both projects. Firefox has already an agile development process, that's what the nightly build is for. It plans to expand that process via the automatic update channel towards *all end users*. And no Linux distribution plans to expand the tests of RC kernels the same way.
Mozilla not dumping Firefox 3.7 (ComputerWorld is full of it) Posted Feb 2, 2010 13:45 UTC (Tue) by dlang (✭ supporter ✭, #313) [Link]
the kernel developers _have_ done major surgery of the scheduler (among other things) as part of the current development process. they've changed the disk scheduler several times. They completely changed the x86 architecture, merging the 32 bit and 64 bit code with almost nobody noticing except those who build their own kernels. and they have done MAJOR changes to locking along the way.
the kernel developers have been pretty good at making sure that they don't break things for users in the process (although there have been a handful of shaky releases).
far fewer people turn on auto-updating of the kernel, but that's far from saying that nobody does it. Doesn't Ubuntu auto-update itself with a generic installation? (I know that it can be configured to do so, I'm just not sure what the default is)
I fully agree that the major releases of firefox have tended to be more disruptive, but the same thing happened with linux when they had the long development cycles. I expect that moving to the continuous/agile development model will improve things (for example, I would expect the awesome bar to be something that the upgrade page told you about and asked you if you wanted to enable, at least when it first came out and you had an existing installation). I also expect them to get this wrong a few times before they learn.
the nightly builds are not a representation of agile development, what changes in them is a fairly random set of patches, there's no thought to what goes in a particular day, and no testing of it before being released. both of these steps are a requirement.
I do not see their plans as being the same as pushing nightly snapshots to end users, I see it as being far closer to the kernel development model.
Mozilla dumps Firefox 3.7 from schedule, changes dev process (ComputerWorld) Posted Jan 17, 2010 9:29 UTC (Sun) by ikm (subscriber, #493) [Link]
So, you wake up one day, and bam! - you've got an "awesome bar" installed. Spicy.
Mozilla dumps Firefox 3.7 from schedule, changes dev process (ComputerWorld) Posted Jan 17, 2010 9:32 UTC (Sun) by rahulsundaram (subscriber, #21946) [Link]
If you read the article and the blog post, it mentions that user visible changes are unlikely be pushed through.
Mozilla dumps Firefox 3.7 from schedule, changes dev process (ComputerWorld) Posted Jan 17, 2010 10:23 UTC (Sun) by ballombe (subscriber, #9523) [Link]
Actually one of the two examples he mentions is "improve typography support" which actually means allowing web designer to display non-free and/or illegible fonts on your screen. Certainly a user visible change.
Mozilla dumps Firefox 3.7 from schedule, changes dev process (ComputerWorld) Posted Jan 17, 2010 10:50 UTC (Sun) by rahulsundaram (subscriber, #21946) [Link]
There are user visible changes and then there are user visible changes. Some changes throws off the user even if they are eventually an improvement. Improved typography support isn't one of them. It can be pushed through without users noticing it much if at all immediately after an update.
Mozilla dumps Firefox 3.7 from schedule, changes dev process (ComputerWorld) Posted Jan 17, 2010 12:46 UTC (Sun) by mattdm (subscriber, #18) [Link]
Web designers can do that *right now* by making GIF or PNG pictures-of-text.
Mozilla dumps Firefox 3.7 from schedule, changes dev process (ComputerWorld) Posted Jan 17, 2010 16:42 UTC (Sun) by Webexcess (subscriber, #197) [Link]
And they do. And they make blocks of text get replaced with flash apps to render the fonts just the way they want (only marginally less horrible)
Ever run webcollage? Aeems like half the images on the 'net are of text
Mozilla dumps Firefox 3.7 from schedule, changes dev process (ComputerWorld) Posted Jan 17, 2010 18:10 UTC (Sun) by Sho (subscriber, #8956) [Link]
Firefox has an option to ignore a site's font wishes and use the user's settings, however. And via the userChrome stuff it also has extensive facilities for users to inject custom CSS into documents, even domain-specific.
Mozilla dumps Firefox 3.7 from schedule, changes dev process (ComputerWorld) Posted Jan 18, 2010 4:29 UTC (Mon) by njs (guest, #40338) [Link]
"User visible" is an ironic phrasing here, since the most substantive effect of replacing image-rendered text with webfont-rendered text is improved accessibility.
Mozilla dumps Firefox 3.7 from schedule, changes dev process (ComputerWorld) Posted Jan 18, 2010 8:18 UTC (Mon) by lkundrak (subscriber, #43452) [Link]
Oh my god! Non-free stuff on the interwebs! I bet you have support for rendering images disabled ;)
Mozilla dumps Firefox 3.7 from schedule, changes dev process (ComputerWorld) Posted Jan 18, 2010 8:17 UTC (Mon) by lkundrak (subscriber, #43452) [Link]
On the other day you wake up, open Google and there's and "o" letters in the logo are shaped as boobs. Something that is not that uncommon to happen. Is there really any noticeable difference between a change that occurs in a web-based application and application that you have installed locally nowadays?
Mozilla dumps Firefox 3.7 from schedule, changes dev process (ComputerWorld) Posted Jan 18, 2010 9:39 UTC (Mon) by ikm (subscriber, #493) [Link]
Only if your computer has been pwned.
Already a reality in Thunderbird Posted Jan 18, 2010 17:02 UTC (Mon) by Trou.fr (subscriber, #26289) [Link]
When mozilla released Thunderbird 2.0.0.23 to fix http://www.mozilla.org/security/announce/2009/mfsa2009-42..., they update the NSS crypto lib from 3.11 to 3.12 which introduced new behaviours regarding S/MIME for example.
|
|||||||||||||
