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@xxxxx
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
--
fedora-devel-list mailing list
fedora-devel-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-devel-list
