When to set VERIFIED in BugZilla?

[James Richard Tyrer]

Carlos Leonhard Woelz wrote:
> On Thu, 11 Mar 2004 10:29:20 -0700, "James Richard Tyrer" 
> <tyrerj at acm.org> said:
> 

> Well, the developer may be travelling at release time. Or he may be 
> working on something else.

Yes, we need to make allowances for this.

> Or he may not know how to fix it.

Good point, there should be some way to ask for help.

> Or he may want to fix the bug, but the may not like being forced to do 
> so.

I don't want to force anyone to actually fix a bug.  My complaint with
developers is when they want to mark the bug as FIXED without fixing it.

> But in general, you are correct: all free software developers "care" for
>  their users, after all, they release their code for free. And they care
>  for the bugs. Most of the rare conflicts between developers and 
> reporters are due to miscommunication.
> 
>>> - 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.
> 
> Unfortunately, people do not maintain their bugs properly. If they did,
>  maintainin a QA team would be easy indeed.
> 
Well we need to start somewhere.  If we can properly maintain 10 current 
bugs then we are that much ahead. :-)  If 100 people would check 1 old bug 
each day, we would eventually get all of the obsolete ones taken care of.
> 
>> 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.
> 
> 
> The current policy is not mark them VERIFIED, as explained in the bugs 
> howto:
> 
> http://quality.kde.org/develop/howto/howtobugs.php
> 
> "(NOTE: Because KDE is missing a QA department which double checks that
>  bugs are really closed, the CLOSED state is not used)."

I agree about CLOSED, that should have to clear someone in charge before
that is done.  But if the reporter (or a Quality Team member that adopted
the bug) has verified it in the next stable release, then it should be
marked VERIFIED as the BugZilla documentation states.  Ideally, we should 
try to have a way that a maintainer could request verification for a bug 
when he thinks that it is fixed.

> If you create a QA team with sufficient manpower, in a framework that 
> makes sense to the KDE core developers, this restriction ends.
> 
I think that the first step is with VERIFIED since current bugs should only
be CLOSED if they have first been VERIFIED.
> 
>> 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.
> 
> I think that the current behavior is to backport only to the last stable
>  branch. Otherwise, one would have to spend limited man power to keep 
> old branches up to date.

Let me explain a little more.  Users almost always report a bug against a
stable release.  This bug should be given more importance as far as QA is
concerned.  It should be considered to be active (it should be on someone's
'to do' list) until it is confirmed as FIXED in a stable release and then
marked as VERIFIED.

I realize that this is contrary to current thinking, but it is my 
professional opinion that the current method isn't working very well -- at 
least it could be improved (a basic ideal of TQM is that things can always 
be improved).

Bugs reported against HEAD need to be treated differently since some of 
them may have a very limited lifetime and ones that are still valid when 
HEAD is branched need to be promoted to BRANCH bugs.

I'm not 100% certain about exactly how HEAD bugs should be treated,
but I can see that they need to be identified as such in BugZilla as the
first step in doing this.

> So all bugs not in the latest head and stable should be closed.
> 
That would certainly help. :-)
> 
<SNIP>
> 
> Yes, the bugzilla software offers this feature, but in KDE we don't use
>  for lack of man power.
> 
I think that if we are going to use a distributed approach that we can 
start with whatever manpower we have and then try to expand.

--
JRT