[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: [QA] To clone or not to clone ( a bug report ) that's the question...



Kevin Kofler wrote:
"Jóhann B. Guðmundsson" wrote:
Please dont mix testers with triagers these are 2 separated teams.

But if one of the teams is not expected to clone bugs, then neither is the
other. :-) So this policy is equally relevant to both teams.

There are exceptions to every rule :)

But indeed in most cases the same applies and from my perspective
more to testers than to triagers.

Testers need to report as correctly and add correct attachments and so
on from the start.

If that goal is accomplished it should really take load off both
triagers and maintainers.

But to reach that goal we need documentation, train testers.

We need test cases and above all what the maintainer wants on a reports against his component.

Unfortunately we have little to nothing on the above :(

I and others are trying to address that issue.

And there are activities which are really both testing and triaging, like
retesting if a bug still applies, at least at KDE upstream this is
something the triagers do. Is there already a policy who's responsible for
such activity? If not, I'd suggest you go talking to the triagers about it.
(Right now, I don't see any such retesting going on, so I get the (possibly
mistaken) impression that each team is expecting the other to do it. ;-) )

Retesting from my perspective should be in the hand of A) the reporter and B) Testers

If maintainers need testing send a mail to the test-list.

If you need test cases or help setting up or anything else from QA
open a ticket in the new fedora-qa trac instance on fedorahosted.

It would be good if you could spend some time of your writing energy
writing testing/ test cases for your components and how you would like
testers to report to components that you maintain.

If I start writing test cases for KDE, I'll never finish... Canned test
plans just don't work for huge GUI apps with many features, unless you have
a specific feature you want to test (e.g. to verify whether a given bug is
fixed).

I disagree I think this is doable, we need to come up with template for the most common nominators in the gui app ( open new save help etc.. ) then just add test cases for those
that are not.
And so far I have not published anything without it being approved
first  either on a QA meeting
or by the maintainer giving his blessing on testing/test cases that it's
like he wants it.

The problem is that the way to handle bug reports is something which affects
packagers and triagers much more than it affects testers. You just file the
bug(s), the packagers and triagers will have to deal with them. So a tester
meeting is a bad place to decide on such a policy.

Again if the report does this properly from start the need of triaging should be to minimum.
In addition, a statement like "There will be no time "pressure" matter since
the guideline has already been written and made so debates can be stuck in
infinite loop until the storage space on the mail server fills up.." makes
you sound totalitarian. Maybe I should give you the benefit of the doubt
and assume something got lost in translation?
My good man your not asking the right question and you don't get answers to question you don't ask.

You should be asking me why do I feel that the -devel list is an
inefficient way to use for communication/intellect discussion invention's and finally a decision making.

I'll try to be more subtle this time and explain in more detail what I mean..

I feel that way because a lot of topics here are..

A) The same ones over and over again and finally when things have settle down we make a release and since there was no solution found or that solution/decision not properly documented and put on a page on the wiki
    the whole thing starts again.

B) A lot of topic start as A but end up as Y or Z so the original topic got lost and the answer to
    that topic still remains unresolved..
( that's why you saw me being so harsh I sensed it start heading in that direction )

C) A lot of great ideas ( and not so great ) come up on this list are we documenting them For example are we putting them on think tank page on the wiki? So they can be revisited when time or manpower are in place to work on some of those ideas I believe we are not doing it and I feel that they just get lost and buried in the paper flood.

D) Allot of the discussion that happens here are without people proposing alternative solution a different approach to the task at hand but instead you see people start taking sides and the debate continues and the task at stays stale. ( And in this case Mark did come with an alternative answer to the questions being asked and so did you later in the game )

D) A lot of topic here do no belong on this list and should redirected to their appropriate mailing lists Redirect end users topic to their list, test related topics to the test list etc..

And the answer to all this boils down to things being as they are because we allowed them to be.

Instead of redirect traffic to they appropriate mailing list...
Instead of taking notes when good solution come..
Instead of when the same topic reappear the person that brought up that topic is redirect to the place that holds the final solution that was found..
.....
....

So my question is..

Are we doing any stats on the traffic on this mailing list as in how many threads are constructive and how many reach final decision vs how many end up in "my side is better than yours" and traffic that should be else where etc.. ?

So the conclusion that I have come to regarding this mailing list can be proven wrong...

JBG


begin:vcard
fn:Johann B. Gudmundsson
n:Gudmundsson;Johann B.
org:Reiknistofnun - University of Iceland;IT Management
adr:Taeknigardi;;Dunhagi 5;Reykjavik;;107;Iceland
email;internet:johannbg hi is
title:Unix System Engineer RHCE,CCSA
tel;work:+3545254267
tel;fax:+3545528801
tel;pager:N/A
tel;home:N/A
tel;cell:N/A
url:www.rhi.hi.is
version:2.1
end:vcard


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]