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

[Bill Nottingham]

Jóhann B. Guðmundsson (johannbg at gmail.com) said: 
> I guess me been spending now 2 hours trying to recreate one of those
> tough to catch bugs ( 678448 ) hard to duplicate, it does not always
> crash bug in evolution at 03:00 in the morning trying to catch that
> sucker to give the maintainer actually something to work with is not
> considered contribution in your books or being involved... 

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*!

> 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.

> 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.

> 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.

> 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. 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.

Bill