Jóhann B. Guðmundsson (johannbg(a)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