However, I’m biased. SQLite is usually not the culprit from other experiences with it. Usually when something goes wrong, it is something else. My own observations tell me that when SQLite became the storage engine for Firefox and Chrome, browser stability improved. I claim that this is a correlation only, but my gut tells me that SQLite contributed to the robustness.

You call that “bleeding edge” and/or “far ahead of the distros”? Fedora has been shipping GTK+ 2.10 since Fedora Core 6 which isn’t even supported anymore, and 2.12 since Fedora 8 which isn’t even the latest version anymore (Fedora 9 is). Rawhide already has GTK+ 2.13 (the development branch heading towards 2.14), so presumably Fedora 10 will have 2.14.

> We’re very involved with them and know that that particular issue
> that Fedora ran across was fixed in a later version. We’re just too
> late in our cycle to take that new package since it would invalidate
> the beta cycle that over 1 million have taken part in.

But Fedora Rawhide isn’t in this stage of the cycle, but in pre-alpha stage, so I suppose (again, it’s not me maintaining sqlite) that this will get fixed in Rawhide by upgrading sqlite, not downgrading it.

http://antennasoft.net/robcee/2008/05/22/howto-unit-testing-linux/

Jeff had a question about security. So at Mozilla we carefully monitor all of those other projects very carefully because we already have to ship them for our other platforms. And we have a long history of delivering timely security updates to users. We would issue an update and distros would know. That being said, we’re sensitive to that particular issue. But my post was more about testing + reliability than security updates.

Simon talked about being on the bleeding edge. What’s interesting is that for many things we’re far ahead of the distros in terms of what’s required. Our cairo is right at the most recent release and FF3 will require GTK 2.10, for example. We’re moving and driving faster than most people can absorb our code. And we’re driving upstream faster and faster, too.

Simon also talked about leaving it up to the distro folks to determine compatibility. Well, they do that today and we know that it’s not working every time. It’s pretty clear that _no one_ is running tests beyond simple smoketesting and using users as beta testers. If distros were doing what you suggest, then it would probably much more acceptable. But they aren’t.

Havoc: Lots of good points but in terms of memory usage there’s a lot of lower hanging fruit vs. including libraries. For example, Pango right now eats tons and tons of memory per process vastly eclipsing the memory that might be saved by including libraries. And I’m not talking about including private copies of pango or gtk. We’re generally compatible with those because they are relatively mature. But cairo and sqlite as examples – we’re at the edge there. We generally know what’s wrong before everyone else does. I specifically remember chasing Carl and Behdad to fix a bug in the X servers (I think Owen finally fixed it?) that we could easily reproduce but no one else could. We’re involved in the projects that we’re shipping and we know what’s going on. So your comments about X compatibility are important and illustrative but they don’t really reflect the situation on the ground that we’ve seen through this release.

Regarding upstreaming and adding value, we would _love_ to have distro involvement in upstream but it’s been pretty tough. Chris and Alexander have both been pretty involved but a lot of that is patch and fix maintainance. We have a serious lack of leadership from the distributions. No one is showing up.

Regarding your comments about communication and individual patches, I couldn’t agree more. That’s not there today, or at least it’s not formalized. And it’s the key. And that was a huge part of my point. For those folks who aren’t doing that and communicating and testing people just shouldn’t be making changes or assuming that system versions should work. But we see a lot of that from the mainline distros, too. Changes for change’s sake. That’s not value by any stretch.

And we can’t scale that to 15 distributions. Or 3, really, that’s just not a reasonable thing to expect Mozilla to shoulder. We need to find a way for the distros to handle that load or at least turn it into a multiplier where everyone is helping each other. My suspicion is that should happen in upstream Mozilla as part of the larger project.

Faidon, Debian’s anti-branding doesn’t have anything to do with making changes. It has everything to do with the image licensing in the package as someone else here pointed out.

Matt: we are working with the sqlite developers, every single day, and continue to on this particular issue. We’re very involved with them and know that that particular issue that Fedora ran across was fixed in a later version. We’re just too late in our cycle to take that new package since it would invalidate the beta cycle that over 1 million have taken part in.

Kevin: once again, it’s not about upgrading or downgrading (and we work with the sqlite developers _all the time_ . (We help back the sqlite foundation as well as work with people.) It’s a question of compatibility and what’s tested. You’re talking about the world as you would like it as opposed to how it is. And I’m sorry your package manager doesn’t offer that kind of flexibility. :(

Yes, the system library (like sqlite) might be buggy sometimes. But the correct fix is to talk with the upstream library people and get it fixed, not sulk and keep the non-buggy version bundled with the application. In the case of keeping a non-buggy version bundled (sqlite), you (mozilla team), are acting exactly like the distributions you are criticizing.

If distros had used mozilla with bundled sqllite, all *other* applications would still be using the the buggy sqllite.

Btw, if you were aware of this bug in this specific version of sqllite, why didn’t mozilla’s ./configure barf on detecting the buggy sqllite version?