Firefox and Linux
Mike Connor
here!)
At the recent Firefox Summit, a group of people led by Chris Aillon
(Red Hat), Robert O’Callahan (Novell), and myself met to discuss
Firefox on the Linux desktop. Historically, there has been a great
deal of tension between mozilla.org and the Linux distros, notably
over maintenance of branches, divergence between distros, and lack of
sustained communication between the groups. All seemed in agreement
that closer cooperation and dividing responsibilities appropriately
would benefit everyone involved. A number of changes were proposed
that have general consensus among the stakeholders.
It is hoped that the proposed changes will drive a stronger and more
balanced partnership among Mozilla contributors, and enable the Linux
community to work more closely with the Mozilla community. More
importantly, we believe this will drive a bigger focus on creating a
better Linux user experience for everyone.
Development
* In the Firefox 3 timeline, establish a strong group of
maintainers to drive and own Linux-specific development. caillon and
roc will likely act as owners here. This is not an exclusionary
group, anyone wishing to help in this effort will be able to
participate and contribute. This certainly includes other projects
that are based on or share code with Firefox (Flock, Iceweasel, etc).
* This group will share responsibility for branch policies for
Linux-specific code. In particular, they may choose to land Linux
integration features on branches.
* The vast majority of downstream patches will be pushed
upstream and into shared CVS, in order to minimize patch sets to
distro-specific packaging/build requirements, with minor exceptions
from time to time.
Distribution
* Most Firefox Linux users are using builds packaged by their
Linux distribution. We will encourage this by having mozilla.com’s
download page point to packages from various Linux distributions.
* The Mozilla Corporation will continue to provide nightly
builds for testing and development, and will make available reference
builds for each release in an unsupported form.
* By minimizing upstream vs. downstream differences, it should
be much easier for Linux distributions to comply with Mozilla
trademark requirements. The current situation involves a great deal
of overhead per distribution due to the large and diverse patch sets.
Therefore the Mozilla Corporation will be able to work with more
Linux distributions around branding than we have been able to in the
past.
Please direct feedback and discussion to the mozilla.dev.planning
newsgroup, or dev-pl...@lists.mozilla.org
caillon has blogged about the changes from the Linux side: http://
christopher.aillon.org/blog/dev/mozilla/20061204-linux-alliance.html
Mike Connor
Firefox Lead
mco...@mozilla.com
Robert Kaiser
> It is hoped that the proposed changes will drive a stronger and more
> balanced partnership among Mozilla contributors, and enable the Linux
> community to work more closely with the Mozilla community. More
> importantly, we believe this will drive a bigger focus on creating a
> better Linux user experience for everyone.
Nice to hear!
> * In the Firefox 3 timeline, establish a strong group of maintainers
> to drive and own Linux-specific development. caillon and roc will likely
> act as owners here. This is not an exclusionary group, anyone wishing to
> help in this effort will be able to participate and contribute. This
> certainly includes other projects that are based on or share code with
> Firefox (Flock, Iceweasel, etc).
I think this should be extended to cover Mozilla-the-platform in
general, even if Firefox and its offsprings are of course the most-used
consumers of that platform.
Thunderbird, SeaMonkey and potential XULRunner apps could also profit
from this a lot, I think.
> * This group will share responsibility for branch policies for
> Linux-specific code. In particular, they may choose to land Linux
> integration features on branches.
Linux integration sounds good, we definately need more in that field -
as said above, this is not restricted to Firefox but touches all
Mozilla-based applications, including XULRunner apps (which hopefully
will increase in number).
I still think we should also think about getting somewhere in the area
of https://bugzilla.mozilla.org/show_bug.cgi?id=140751 (KDE integration)
in some similar style to what we are already doing wrt GNOME. Ideally
the build would detect which desktop environment is running and use that
one to e.g. retrieve system settings it can reuse (if the user choses to
do that), display a native filepicker if wanted, etc. (note that I'm not
talking Qt here, gtk2-cairo gfx is fine, just system/desktop integration
is what I'm talking about here, which is independent of the toolkit in
an ideal world.)
Robert Kaiser
Mike Connor
On 5-Dec-06, at 2:24 PM, Robert Kaiser wrote:
> I still think we should also think about getting somewhere in the
> area of https://bugzilla.mozilla.org/show_bug.cgi?id=140751 (KDE
> integration) in some similar style to what we are already doing wrt
> GNOME. Ideally the build would detect which desktop environment is
> running and use that one to e.g. retrieve system settings it can
> reuse (if the user choses to do that), display a native filepicker
> if wanted, etc. (note that I'm not talking Qt here, gtk2-cairo gfx
> is fine, just system/desktop integration is what I'm talking about
> here, which is independent of the toolkit in an ideal world.)
I'm not sure how much is toolkit and how much is possible in the way
you're describing, but I get the impression no one really wants to do
this work, or it'd have been done by now. I even offered to work
with people to make toolkit widgets KDE-friendly, but no one even
hinted at wanting to do it.
-- Mike
Robert O'Callahan
> I still think we should also think about getting somewhere in the area
> of https://bugzilla.mozilla.org/show_bug.cgi?id=140751 (KDE integration)
> in some similar style to what we are already doing wrt GNOME. Ideally
> the build would detect which desktop environment is running and use that
> one to e.g. retrieve system settings it can reuse (if the user choses to
> do that), display a native filepicker if wanted, etc. (note that I'm not
> talking Qt here, gtk2-cairo gfx is fine, just system/desktop integration
> is what I'm talking about here, which is independent of the toolkit in
> an ideal world.)
Fine idea, but no-one has been interested in stepping up to do this.
Rob
Alfred Peng
It's great that different distros and mozilla.org can work together
on Linux/Unix community. Since Solaris has the same gnome desktop
environment and it has some similar issues with other Linux distros, our
team in Beijing would also like to be part of this cooperation and make
it happen soon.
In the latest Solaris, Firefox2.0 and Thunderbird1.5 have become the
default browser and mail client, and Mozilla1.7 has been removed. Our
work contains the bug fixes of Solaris specific bugs and some
Solaris/Linux common bugs. We'll carry on this in the future. As for
Firefox on Solaris now, we don't hold any patches by ourselves and all
our patches are upstreamed to the community. The code to make the
Solaris bundled builds and mozilla.org contributed build comes from the
community cvs tree directly.
At the same time, the Solaris contributed builds are now in the
release note page. It's a good idea to combine them with the other Linux
distributors so that users can get the corresponding builds from
mozilla.org. To ensure the quality of the contributed builds, it's
better that different distros can join the community test cycle before
the final official release, and try to figure out how to avoid the
resource overlap in the test work.
Regards,
-Alfred
Mike Connor wrote:
> (Posted to my blog last night, forgot to crosspost, please follow up
> here!)
>
> At the recent Firefox Summit, a group of people led by Chris Aillon
> (Red Hat), Robert O’Callahan (Novell), and myself met to discuss
> Firefox on the Linux desktop. Historically, there has been a great
> deal of tension between mozilla.org and the Linux distros, notably
> over maintenance of branches, divergence between distros, and lack of
> sustained communication between the groups. All seemed in agreement
> that closer cooperation and dividing responsibilities appropriately
> would benefit everyone involved. A number of changes were proposed
> that have general consensus among the stakeholders.
>
> It is hoped that the proposed changes will drive a stronger and more
> balanced partnership among Mozilla contributors, and enable the Linux
> community to work more closely with the Mozilla community. More
> importantly, we believe this will drive a bigger focus on creating a
> better Linux user experience for everyone.
> Development
>
> * In the Firefox 3 timeline, establish a strong group of
> maintainers to drive and own Linux-specific development. caillon and
> roc will likely act as owners here. This is not an exclusionary
> group, anyone wishing to help in this effort will be able to
> participate and contribute. This certainly includes other projects
> that are based on or share code with Firefox (Flock, Iceweasel, etc).
> * This group will share responsibility for branch policies for
> Linux-specific code. In particular, they may choose to land Linux
> integration features on branches.
> _______________________________________________
> dev-planning mailing list
> dev-pl...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-planning
>