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