When to set VERIFIED in BugZilla?

[James Richard Tyrer]

Carlos Leonhard Woelz wrote:
> On Thu, 11 Mar 2004 05:47:41 -0700, "James Richard Tyrer"
> <tyrerj at acm.org> said:
> 
>>Henrique Pinto wrote:
>>
>>>James Richard Tyrer wrote:
>>>
>>>
>>>>Hello! :-)  Perhaps we need to discuss this further, but aren't we 
>>>>starting a QA department?  Isn't that what we are doing here?
>>>
> 
> The KDE Quality Team is a gateway between people who care about the
> quality of the KDE and the KDE normal development process. The objectives
> are:
> 
> 1) Support new contributors, with any info they need
> 2) Organize the tasks to be done, to make it easy for new people to
> integrate.
> 
> A very good subproduct of 2 is a global view of the main application
> issues. This is important because non programmers usually don't have
> strong preferences about tasks: they just what to help their favorite app
> / desktop.
> 
> 
> 
>>>AFAIK, (Quality Team != QA Team).
> 
> 
> Exactly.
> 
> See this post so I don't have to write it again.
> 
> http://developers.slashdot.org/comments.pl?sid=99037&cid=8446426
> 
> 
>>If you mean that the KDE Quality Team is not supposed to do Quality 
>>Assurance, then IIUC you would be WRONG.
>>
>>If you don't understand what Quality Assurance is: it means seeing that
>>the 
>>bugs actually get fixed.  Is it your understanding that the KDE Quality 
>>Team isn't going to do that?
> 
> 
> Quality Assurance is a formal process we currently lack the man power to
> start and maintain. It is not out of the scope of the Quality Team: it is
> just that we don't have anyone currently doing that. Do you want to start
> one?
 >
> As a curiosity, how do you think we could solve the following problems?
> 
> - Since contributors are volunteers, how can you *force* people fixing
> stuff?

You shouldn't have to "force" anyone to fix their bugs.  They should want 
to do it, but if not all you can do is offer to help.

> - Even if you *force* them to do so, a strict scheme like that wouldn't
> scare away good developers? KDE is supposed to be fun.

I realize that many people have different contingencies of reinforcement. 
I personally take satisfaction in a job well done.  Perhaps that is just my 
personality or perhaps it is a consequence of my professional training. 
So, I can not imagine that someone who wrote code would not want to fix it 
if advised of a bug in it.

> - Who would do the work of re-checking all the bugs?

My suggestion, already posted somewhere else (CC'ng does help), is that 
first people that post bugs can accept the responsibility for the QA job 
for their bugs.  That they should confirm that they actually have been 
fixed in the appropriate release and mark them as verified.  A next step is 
that QA team members could also adopt bugs if the reporter was a user that 
didn't want to take the responsibility of doing the QA.

So, my question was when I should mark bugs which I reported and had 
confirmed fixed as VERIFIED?  I think that if they were reported against 
the BRANCH that they should be verified if they work in the current release 
of the branch.

Clearly bugs reported against HEAD should be treated differently -- so that 
is another issue that bugs reported against HEAD should be identified as 
such (on BugZilla) by the reporter.

> A good QA proposition would have to deal with all that. I have not yet
> thought of a suitable solution to these problems. You could start a pilot
> project, if you find an application maintainer that agrees with you, and
> we could draw conclusions from that.

What I currently find odd is that we totally reject the idea that bugs 
which have been verified as fixed should not be marked as VERIFIED in 
BugZilla so that that information is available on the database.  The 
BugZilla site is quite clear about what should be done:
<<
VERIFIED
QA has looked at the bug and the resolution and agrees that the appropriate 
resolution has been taken. Any zombie bugs who choose to walk the earth 
again must do so by becoming REOPENED.
 >>
> In the mean time, there is a lot to do. We can make KDE better by writing
> docs, artwork, 

I have done a little artwork (icons)

managing bugs,

What I currently find odd is that we totally reject the idea that bugs 
which have been verified as fixed should not be marked as VERIFIED in 
BugZilla so that that information is available on the database.  The 
BugZilla site is quite clear about what should be done:
<<
VERIFIED
QA has looked at the bug and the resolution and agrees that the appropriate 
resolution has been taken. Any zombie bugs who choose to walk the earth 
again must do so by becoming REOPENED.
 >>
How can you manage a bug if the *final* results of doing so are not reported?

programming, fixing usability issues,

I do bring usability issues to the usability list.  The last two times I 
was basically flamed for doing so.  When I CC the usability list, I do so 
with the expectation that a *different* discussion will occur on that list 
than would occur on the 'devel' list.

> helping fellow contributors, etc...

The "etc" I do is contributing to the support lists.  Doing this means that 
I become aware of user issues.  I feel that I should be able to contribute 
by bringing these issues to the attention of others.  So far this has not 
worked out very well.

--
JRT