reporting bugs upstream : nothing on the wiki?

"Jóhann B. Guðmundsson" johannbg at
Mon Jul 12 20:15:39 UTC 2010

  On 07/12/2010 07:32 PM, Ankur Sinha wrote:
> Why is it "simply ludicrous"? It only needs following simple
> instructions. You don't really need to learn anything for this. I'm not
> asking $grandma to do it

How are you going to determine that's it's was not '$grandma' was not 
actually the one that filed the report in the first place?

> That's no where to a solution. Please, constructive ideas would help.
> You'll have to explain "unnecessary confusion, burden and what not on
> the whole QA community". I got no clue what that refers to.

Have you really never filled a bug upstream that got rejected because of 
the component that was shipped with $distro ?
Standard procedure in some of them is simply to start with what they 
have in git.

Let's start playing that ping pong game with new reporters shall we..

> It isn't always possible to do. I've seen the amount of bugs that
> packages receive, bridging all of them to upstream isn't really possible
> at times.

If the maintainer does not have the time to maintain his own component 
he should ask for ( more ) co maintainer ship or do the community and 
the distro a favour and drop the component from Fedora or allow some one 
who does have the time and the skills necessary to take over the component.

We gain absolutely nothing other than bad reputation and frustration 
amongst end user by shipping components that get zero to no maintenance 
and response in bugzilla, an extra loads to triagers who triaged the bug 
( if they did that is ) frustration of reporters that had over 
expectation on the result of his first report and added loads on forums 
and #fedora to either come up with workaround or simply interect with 
all end users that are using that broken ill maintained ( even sometimes 
dead upstream ) component.

Please take the time to do the math of how many upstream bugzilla 
reporters and triagers should be subscribed to of all the components 
let's simply start with critical path and amount of documentation of the 
interaction on procedure on all of those upstream bugzilla instances 
need to be in place. ( you can move on to Full blown shipped spin if 
that does not make you realize that it's dead end )


More information about the test mailing list