reporting bugs upstream : nothing on the wiki?

[Michael Schwendt]

On Mon, 12 Jul 2010 20:15:39 +0000, Jóhann wrote:

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

Earlier in your mail you've raised some valid questions. But please stop
there. Don't extend it into hostility. Fedora is open enough for anyone
with time, skills, and *interest* to contribute something. If you think
something sucks, step forward and contribute. It is not necessary for an
existing packager to orphan a package before somebody else could help.
Such a person would need to submit patches to the upstream project anyway
and only touch the Fedora packages when nobody else would apply the
patches. Further, you should know that for some types of bugs, not even
upstream knows all the code well enough to find the solution quickly.
For example, it is common for some types of programming bugs (such as
heap/stack corruption, concurrency, race conditions) to result in
stacktraces which are only about side-effects. With a tool like ABRT it is
normal to see a flood of reports until the real problem is fixed [possibly
in a dependency].

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

And we gain absolutely nothing either by having bugzappers close tickets 
with scripts instead of contributing real triaging.

If you have means to determine "components that get zero to no
maintenance and reponse in bugzilla", please use them more wisely instead
of ignoring such a problem until dist EOL.
 
> 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 )
> 
> JBG