When to set VERIFIED in BugZilla?

[Marc Heyvaert]

Hello all

Just jumping in because bugs is one area where I want
to become active...I may have missed some of the msg
that where posted earlier.

Could someone explain me what the life cycle of a KDE
bug is then,

Especially how it eventually disappears. I mean, when
it is resolved, fixed or whatever, it has to be
closed, hasn't it?

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



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

For me a bug is a bug, so should be reported. If I
were a developer, I would even put *all* bugs in the
database, even those that I discovered myself, because
it is an easy way to track all your work and to
organise the info that is needed for the problem at
hand. It is extra documentation in a way. But not all
developers seem to think this.

It is true that most users report bugs that appear in
a stable branch, so backporting should be done. But
vertainly not further than the latest branch, if a
user goes through the trouble of updating his packages
it will be the latest stable release anyway. 

Marc

__________________________________
Do you Yahoo!?
Yahoo! Search - Find what you’re looking for faster
http://search.yahoo.com