[fedora-india] Fwd: 2009-06-24 - Fedora QA meeting Recap

sankarshan foss.mailinglists at gmail.com
Thu Jul 16 14:12:42 UTC 2009

To be read in the context of: <http://jlaska.livejournal.com/5693.html>


---------- Forwarded message ----------
From: Adam Williamson <awilliam at redhat.com>
Date: Thu, Jun 25, 2009 at 9:55 PM
Subject: Re: 2009-06-24 - Fedora QA meeting Recap
To: For testers of Fedora Core development releases
<fedora-test-list at redhat.com>

On Wed, 2009-06-24 at 23:08 +0000, "Jóhann B. Guðmundsson" wrote:

> The reason for the lack of the needed information on a report is in
> most cases simply that the reporter has not a clue what to include in
> the report itself and is not mandatory to provide that information.The
> underlying problem is not the reporter nor the triager which often ask
> the reporter to include wrong information because the triager has no
> better clue what to include in the report so he ask for the most
> common include case ( usually to include /var/log/messages). The
> problem is that the maintainer(s) them self have failed to provide
> this information or has done so only to the reporter on a report
> bases.When a maintainer introduces a component into Fedora it should
> be mandatory for him to provide this information along with how to
> enable debug output and to provide test plans for the component.

I think you've definitely accurately identified a problem here and it's
important to improve this situation, but making things compulsory for
maintainers isn't always the best way to go :). For instance, I recently
added congruity as a package to Fedora (didn't push any builds yet, I'll
do it soon). If I'd had to fill out some form to explain what info
should be provided in the case of bugs, that would have just felt like
another annoying hoop to jump through. I also might not really _know_
what to put there, yet, since I haven't seen what it does when it
doesn't work right, so I'm not really sure how I'd go about diagnosing a
problem. But if it were to happen, I'd work it out.

So I'd say it's more something we should figure out a process for
triagers and maintainers to work on together, without beating anyone
over the head with a stick. We should be taking the initiative in asking
our maintainers what information they need on reports for the components
we work on. If they're not replying to these questions, we should ask if
there's something wrong with how we're asking them, and if not, take it
to the appropriate level to explain why we really need co-operation from
maintainers on this. Rather than jumping straight to getting out the big
stick :)

If a triager were to develop a sudden desire to triage bugs on any
package I maintained, and came and asked me in a productive way what
sort of information would be required on bugs of the kind BUG_REPORT_X,
I'd happily help out with that, and I think most maintainers probably
would. But asking them to do it cold when initially importing a package
might be a bit different.
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org

fedora-test-list mailing list
fedora-test-list at redhat.com
To unsubscribe:

http://www.gutenberg.net - Fine literature digitally re-published
http://www.plos.org - Public Library of Science
http://www.creativecommons.org - Flexible copyright for creative work

More information about the Fedora-india mailing list