2010-01-11 @ 16:00 UTC (11am EST) - Fedora QA Meeting Recap

Adam Williamson awilliam at redhat.com
Tue Jan 26 01:04:33 UTC 2010


On Mon, 2010-01-25 at 01:00 -0500, Christopher Beland wrote:
> On Tue, 2010-01-12 at 11:13 -0500, James Laska wrote:
> > * jlaska to reach out to beland for guidance/ideas on how to
> document
> > the process (or point to existing documentation) for how bugs are
> > noted
> > (common_bugs, release notes, install guide etc...) How to determine
> > which bugs land in which place 
> 
> I'm not sure why my name came up, but here's my take on the question:
> 
> It's clear that any unintentional "known issues" need to get added to
> Common Bugs, and that page is already self-documenting:
>  https://fedoraproject.org/wiki/Bugs/Common#My_bug_is_not_listed
> 
> There's only one area which might be improved - CommonBugs keyword. 
> Is
> there are particularly good workflow reason why it exists?  Does
> someone
> come through periodically and check to see if all the bugs tagged with
> this keyword are actually listed on the wiki page?  Does it motivate
> developers to see this keyword?

Discussed at the meeting, but to recap - yes, jlaska and I periodically
check CommonBugs-marked bugs. It doesn't really exist to motivate
developers (though if it does, that's an added bonus). It mainly exists
for two reasons: as a way to request a bug be added to CommonBugs if you
don't want to do it yourself (and also for people who edit CommonBugs to
make a quick 'mental note' to add a bug in future), and it also helps
if, say, you're subscribed to a bug, see that it gets fixed, and then
notice that it's marked CommonBugs with a URL, so there's a Common Bugs
entry which should be updated to reflect that the bug's been fixed.
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org
http://www.happyassassin.net



More information about the test mailing list