Per user vs. system settings in GNOME 3 (was Re: How do we change fonts now)

"Jóhann B. Guðmundsson" johannbg at gmail.com
Mon Feb 21 21:43:37 UTC 2011


On 02/21/2011 05:39 PM, Bill Nottingham wrote:
> Nowhere did I say that. What I said is...
>
>> Owen has made it perfectly clear to me that they wont be fixing any UI
>> Design ( bugs ) before GNOME 3.0  So excuse me that I dont jump on a
>> horse ride to Gnome land file a UI design (  bug ) that wont get fixed
>> anyway before we release F15....
> ... if you have interest in getting a bug fixed, then work where the
> maintainers of the software work to get their issues handled, wherever
> possible.
>
> Is it a pain sometimes? Absolutely.
> Does it require sublimating your ego? Yes.
>
> But it's the best way *to actually get your issues fixed*!
>

There is no such thing as an *individuals* issue bugs affect more then one.

>> Regarding the whole file upstream mantra that just takes the load of the
>> maintainer in question and puts it on the reporters.
> That's an unfortunate reality of how it works best.
>
> Take two scenarios:
>
> - A piece of software, with an upstream bug tracker. The maintainer is
>    expected to work there, take the lists of issues that need fixed, track
>    their issues there, etc.
> - A piece of software, where the maintainer is expected to balance their
>    issues across ten separate downstream bugtrackers, people that just send
>    them random e-mail, people that poke them on irc on multiple networks,
>    and so on.
>
> Sure, the second of these takes the load off the reporters. But it doesn't
> actually work well to develop software coherently, remember all the issues
> that need addressed, and so on.

Those issues exist there solely by the hands of the maintainer(s).

The better they test they code before exposing it to end user(s) reduces 
the reports both from their upstream and any downstream trackers they 
are involved with..

That is the reality...

>> Today we are focusing on X that would require us to have an upstream X
>> account tomorrow we are testing KDE that would require us to have on
>> upstream KDE account on sunday it x on monday it's y. etc etc I'm pretty
>> sure you can do the math here..
> *shrug* I have a bz account at FreeDesktop, GNOME, KDE (iirc, haven't
> used it much), even the pit of despair that was/is the SF bug tracker. I'm
> still alive.
>

I have bz account on various places and probably 2 on Gnome one from my 
<2 Gnome release testing heck if I did have one on helix code here back 
in the day I'm also still alive so?

>> Now let's say I was new I had interest to join the reporters group of QA
>> and I have barely gone through our documentation and learned our
>> bugzilla behavior when it's demanded of me that I create account and go
>> through upstream documentation to learn their bugzilla behavior to file
>> bug there ahh.. but it gets more complicated not all upstream is using
>> bugzilla let's all increase the learning curve for the new guy just so
>> we can save the maintainer some time...
> The new guys (aka, end users?) that don't have an understanding of processes
> should probably not be using the same bug trackers as the developers, for
> better or worse. (It's why most organizations don't have engineering
> working on anything that comes through support, for example.) Experienced
> people taking leadership positions in testing, development, packaging
> should be held to a higher standard, IMO.
>

End users reporting are taking their first step becoming reporters when 
they file their first report and given how their responded to on their 
first report will determine if they will continue reporting and become 
valuable members of the ( QA ) community and it is interesting to see 
you mention that certain people should be held to certain standards 
given some packagers/maintainers interaction ( or lack there of ) in 
bugzilla and other places..

We need to have a healthy grow of reporters in our community for various 
of our QA processes to work ( like proven testers ) and to do so we need 
to have the least barriers of entry point along with the fact that we 
cannot assume certain level of skill set or experience from a reporter ( 
which btw is why I write spoon feeding how do debug documentation ) when 
he is reporting and we need to give as much positive feedback and 
encouragement back to him and it's is up to us ( us as in the community 
) to gradually teach him and be a supportive step in his journey to 
become a valuable useful reporter which when ready and willing they 
themselves will join and start working directly with upstream and that 
is the reason why I'm am so opposed to maintainers directing reporters 
upstream just to make that clear.

Looking at reporters as nuance with issues a thorn in maintainers side 
which unfortunately many maintainers do  is not the way to go.

Fortunately not all maintainers share the same view and look at 
reporters as a valuable asset at their disposal when needed.

>> So if you feel what I wrote was some condescending bullshit then by all
>> mean feel that way everybody has a right of their own opinion.
>>
>>  From my perspective it seriously feels like I need to draw a picture for
>> people to understand what I'm getting at when maintainers scream
>> upstream because those maintainers usually look at us reporters as a
>> nuance and have a hard time looking at things from our side...
> To put it simply; you had an issue. You are *asking* someone to fix it
> for you. They mentioned the best way to get it addressed. You then
> responded that you refuse to operate that way based on your principles
> of how development should work.

Oh I did?

Care to point me out where I mentioned that I refused to operate that 
way based on my principal of how development should work?

I'm just a bit curious to know since me refusing to work directly with 
upstream Gnome is strictly personal.

>   There's almost no way that doesn't come off
> as arrogant and obnoxious, which is generally *NOT* the best way to
> influence people to fix the issues that you have.

I merely *pointed* out that it's was hard to different when your are 
being asked to provide the "root" password or the logged in "user" 
password or the "Administrator" password.

If you think I'm egotistic,arrogant and obnoxious and feel offended that 
I wont go upstream to report this then by all means be offended.

Again everyone has a title to their opinion and if that's your personal 
opinion of me than so be it live goes on..

If those "issues" wont get fixed that will reflect badly on "Gnome" ( 
and unfortunately the project in whole since we have a "Default" which 
would happen regardless of what that default might be and any issue that 
it might have ) but hopefully those users wont leave "Fedora" but 
instead try some of the other *DE we have and strengthen the community 
surrounding them and vs versa for any other *DE and any issue they might 
have..

There is absolutely nothing more of value I can add to this thread I've 
explained as much as I can and as best as I can and since this thread is 
turning into personal attack against me this will be my last response to 
it..

JBG


More information about the desktop mailing list