Firefox 2.0 parallel install

[Christopher Aillon]

Gawain Lynch wrote:
> On Sun, 2006-10-22 at 14:34 +0200, Remi Collet wrote:
>>>> /usr/lib/firefox2-2.0/* 
>>>>     
>> Why not /usr/lib/firefox-2.0/* (this will create an conflict when
>> updating to official FF2 (update to FC7) ) as i think firefox-2 will
>> probably don't obsolete firefox2 and so, remember user to uninstall it.
> 
> If I go down the path of adding this to extras then I would like
> agreement from caillon that firefox-2.x in fc7 would obsolete firefox2
> otherwise it would open up a world of hurt.

I was about to complain that people were clamoring for this without 
hearing out my opinion for precisely the reason you just stated.  I'm 
less grumpy, so thank you for the consideration, Gawain.  I really do 
appreciate that.

However, I'd urge this to not happen.  There are technical, legal, and 
practical reasons.

- Honestly, most people really don't care.  For example, in the days 
I've had my binaries up, I've only garnered 83 downloads as of this 
writing.  That's with my blog post, with Remi's, yours and who knows how 
many others plus aggregation.  That's under 10 downloads a day on 
average, but I had 44 downloads after day 1.
- Firefox 2.0 only adds a few minor "nice-to-have" features that you can 
already get with extensions to 1.5.  This really should be called 
Firefox 1.5.1 instead of 2.0 (the internal gecko number version this 
minor change), but it's called 2.0 for marketing purposes.  They feel 
that they will get more people downloading it with a major version bump 
as opposed to a 1.5.1 release.  Looks like the marketing hype is 
working.  Let me state it plainly for everyone: There is nothing 
extremely compelling about Firefox 2.0.  Firefox 3.0 on the other hand 
will be very compelling for both features, linux support, and embedding 
support.  I am seriously considering pushing 3.0 into FC6 and even FC5, 
and have been making noises for a while about that being the next upgrade.

Those two reasons alone make Firefox 2.0 not worth adding to older 
releases.  However, for the small amount of people that do care, here's 
some more reasons I think this should be avoided.

- There are potential legal ramifications as the binary must be called 
"firefox", not "firefox2" (though this can probably be worked out with 
upstream).
- There is potential for a maintainer to accidentally or willingly get 
Fedora entangled into a legal battle for trademark violations by 
including non-approved patches.  I haven't looked at the changes made 
but essentially if they differ from what I have published, which I'm 
guessing they do, they need to be checked.
- Maintenance.  It will add a burden on me and on the maintainer.  There 
are some patches (especially with pango) which need to be added to all 
RPMs we ship as there's an agreement to continually fix those.  This 
means that for some patches I do for rawhide, I have to make sure FC6 
and FC5 gets it.  Adding more RPMs to that mix means that I have more 
work to do with either getting ahold of the maintainer or doing the 
rebuild work myself.  Or the maintainer must hawk over my packages night 
and day looking out for changes.
- Other distros are officially supporting 1.5.0.x and I'd like to pool 
resources somewhat.  This is a good approach to tackling such large 
packages with very few maintainers.  1.5.0.x has been getting more linux 
specific fixes than 2.0 has from distros.

And most importantly, no matter who ends up maintaining this in Extras, 
I am ultimately responsible for it as I'm the Fedora contact for 
upstream, have the upstream cred, and am part of the security and 
release teams upstream.  Anything that happens between Extras and 
upstream will come back to me if only for my opinion.  Questions about 
processes, etc. from whoever would own the Extras package will likely 
come through me.  I'd be responsible for making sure security fixes get 
out at roughly the same time as the Core versions.  And this is an 
unnecessary responsibility.

If people care that strongly about having the latest greatest on their 
system, use rawhide.  It's not really that unstable.  If you're on 
fedora-devel-list, you're already ahead of the curve, and will get heads 
up for breakages anyway and solutions and workarounds for fixing things 
in the times when things break.  People are getting far too version 
hungry for actual releases.