When to set VERIFIED in BugZilla?

[Carlos Leonhard Woelz]

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

Correct.
 
> > - 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.

Well, the developer may be travelling at release time. Or he may be
working on something else. Or he may not know how to fix it. Or he may
want to fix the bug, but the may not like being forced to do so.

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.

> 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)."

If you create a QA team with sufficient manpower, in a framework that
makes sense to the KDE core developers, this restriction ends.

> 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. So all bugs not in the latest head and stable should
be closed.

> > 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.

Yes, the bugzilla software offers this feature, but in KDE we don't use
for lack of man power.

> > 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)

I have seen it, thank you. You are a perfect member for the quality team:
someone worried about the whole of the applications, with many talents.

> >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?

I agree. Show me a feasible alternative. Why developers close the bugs
themselves? Because people do not follow their bugs, and there is no QA
team.

Cheers,
-- 
  Carlos Leonhard Woelz
  carloswoelz at imap-mail.com

-- 
http://www.fastmail.fm - I mean, what is it about a decent email service?