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.
--
fedora-devel-list mailing list
fedora-devel-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-devel-list
