Mark wrote:
On Thu, Dec 18, 2008 at 10:49 PM, Rahul Sundaram
<sundaram@xxxxxxxxxxxxxxxxx> wrote:
Mark wrote:
Redhat is eager to change things when they might get in trouble if
they have it in.. like codec support. You guys are killing out more
then enough in other packages to save your own asses and you tell us
that you want to follow upstream..
If a software is not included at all in Fedora, then there is no
modification and upstream is preserved as it is. For many others like in the
case of gstreamer, the extra codecs or functionality is separated cleanly as
plugins and we don't have to modify anything but only pick and choose, what
we can include. Only as a last resort, is something patched and that is
because it is the only legal choice at that point. It is still a unfortunate
divergence and adds a ongoing maintenance overhead for the package
maintainers. Adding more pain to the problem doesn't make sense.
Refer
http://fedoraproject.org/wiki/PackageMaintainers/WhyUpstream
i agree on that with CODE changes.
i disagree on that with config changes! config things are just the the
values set by the creators that they think are best to use. That
doesn't make them THE best settings out there. Don't be so freaking
hard on config changes!
Code and configuration cannot be easily separated like this and changes
always have a associated cost. Atleast in one package I maintain, a very
small and simple configuration change resulted in a potential security hole
(only in rawhide for a short while but still ..)
I am just trying to get a clear signal out that there is something in
fedora that the people using fedora want to see different
It doesn't seem the right path to doing that, to me.
Rahul
I just can't resist to comment on you just to BREAK your arguments
that settings have to be made upstream as well.
Oke. I browsed through the fedora cvs for a few minutes looking for
firefox because i know a setting got in there a while ago to "fix"
something.
That something was that the scrolling was going slow in firefox when
compositing was enabled. which is especially notable in gmail in long
messages.
Now that firefox issue never got resolved on fedora but the value:
general.smoothScroll was set to true while the upstream was false!
and that setting just lets firefox scroll with less lines per scroll.
the issue that firefox scrolls slow when compositing is enabled is
still valid.. still not fixed..
and that conf value is still set to true! while upstream is still
FALSE! that setting got through relatively fast (mather of hours or
days.. don't remember exactly) and the proof is here:
http://cvs.fedoraproject.org/viewvc/devel/firefox/firefox-redhat-default-prefs.js?view=markup
Now that's just one thing you guys changed in firefox. there is a lot
more that got changed in firefox and isn't changed upstream! just go
through the firefox files on the fedora CVS.
So your argument that confis settings will have to be applied upstream
is hereby smashed to the ground because other packages don't keep that
same "deal".
Other packages get config setting changes so WHY are you making such a
hard deal of nautilus?
O and don't believe that you guys don't patch the hell out of
packages? look at apache, look at php, look at mysql, look at kde...
look at nearly EVERY package that is in fedora.
And those patches are the hard ones!
Then for the fedora bookmarks in firefox.. those are relatively easy
to add but to we want them? are those requested by the users? NO! are
those done anyway? YES!
are those upstream? NO! are those in fedora? YES!
And to your latest post here:
On Fri, Dec 19, 2008 at 12:06 AM, Rahul Sundaram
<sundaram@xxxxxxxxxxxxxxxxx> wrote:
Suren Karapetyan wrote:
Not in this case.
Here we can easily separate a default checkbox from code change.
Nothing is as easy as it looks. You have to patch software, patch
documentation, patch translations and test them. All deviations from
upstream carry risks. Then there would be differences between upstream and
some distributions. Users who have to deal with multiple distributions have
to deal with these differences.
If there is a change required, talk within the upstream community or have a
real discussion with the package maintainers and try to convince them
instead of pointless voting in the development mailing list (which is far
from representative of a regular user base, would make them feel forced). If
the maintainers have agreed to a vote, then fine. If not, it makes no
difference and just wastes time. Don't do it. It just provides false hope
and leads to more disappointment. Not worth it, for a easily changed
setting.
Rahul
Oh men, i'm so starting to hate you.
your reasons are broken and smashed to the ground by what i said
above! get fedora in line with what you say or don't say a thing!
So.. you want us/me to contact the maintainers of nautilus. So be it!
Will do so in my next post
Sorry for the mad post but i'm just getting kinda frustrated by one person here.
No need to get frustrated, but I agree with Your points.
Expecting configuration changes to happen upstream is sometimes crazy.
Let's take the kernel as an example.
Here upstream default config is the one in Linus'es tree's .config file.
It's very easy to understand that everybody isn't going to use that
config file.
And we don't... in fact nobody does, cause there is only one default
upstream config and it WON'T fit everyone.
So we do change the config, even more we add our own patches (in fact a
hundred of them).
If we weren't going to do config changes (and not only them) we wouldn't
need and Usability/Friendliness experts.
In fact we wouldn't need ant developers/maintainers too.
A build-system would be the only thing we need.
And now about this particular case.
I think it's quite easy: if in some way we find out that most people
want/use browser mode we MUST switch to it.
It's called democracy (not that I believe in it much :) but it can work
sometimes).
If majority of users changes that setting to "true" every time they
install fedora, then it should be the default.
--
fedora-devel-list mailing list
fedora-devel-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-devel-list
