Mark,
Remember these items if nothing else from this experience.
1. Rahul is an abrasive boob who makes things sound like he is the be all and end all,
the total authority, the "Omega" if you will.
2. Don't ask for a "vote" ask for a poll to gauge interest in the topic, it
will keep gentlemen like Rahul off your ass.
3. Don't cross post to the -devel list, the Developers (really mostly packagers) are
not users, they are power users or more.
Robert 'EvilBob' Jensen
P.S. I vote next time Rahul shows up at a public event we paint him purple and make like a
pinata. +100
P.S.S. BTW the first setting I change on every new install is "Always open in browser
windows" even before running "yum update"
----- Original Me ssage -----
From: "Mark" <markg85(a)gmail.com>
To: "Development discussions related to Fedora"
<fedora-devel-list(a)redhat.com>
Cc: "Community assistance, encouragement, and advice for using Fedora."
<fedora-list(a)redhat.com>
Sent: Thursday, December 18, 2008 5:14:21 PM GMT -06:00 US/Canada Central
Subject: Re: Call for vote: Nautilus use Browser view for fedora 11
On Thu, Dec 18, 2008 at 10:49 PM, Rahul Sundaram
<sundaram(a)fedoraproject.org> 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-...
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(a)fedoraproject.org> 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.
--
fedora-devel-list mailing list
fedora-devel-list(a)redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list