your RESOLVED->CLOSED changes

Nathanael Nerode neroden@twcny.rr.com
Fri May 23 15:47:00 GMT 2003


Wolfgang Bangerth wrote:
>>Right now, in order to change to CLOSED, you need to edit the bug two times,
>>and this is suboptimal.
> 
> 
> I wasn't even aware of this. Which might or might not indicate that the 
> process is too complicated.
> 
> Regarding the existence of the two states at all: I have argued previously 
> that that's unnecessary. Nathanael says that we need them for the 
> otherwise lack of QA in gcc, but I think that's not correct: every patch 
> for a bug should come with a testcase, so at least in theory a bug that 
> has once been fixed cannot reappear because it would show up in the 
> testsuite.
Note that I'm arguing for "VERIFIED", not for "RESOLVED".  I agree that 
the presence of *three* states (RESOLVED, VERIFIED, and CLOSED) is 
undesirable.  The point of VERIFIED is to hold the bugs which are "fixed 
on mainline, not for 3.3", which can keep getting duplicate submissions 
for many months.  (And we should, if we keep it, make VERIFIED bugs 
searched by default by users looking to submit a new bug without 
duplicating an old bug.)  RESOLVED serves no separate purpose for GCC.

> I get the feeling that this requirement is quite thoroughly handled. If it 
> is not in some cases, then I think it is an undue burden on the bugzilla 
> people if they have to maintain two states for _all_ bug reports. It's an 
> undue burden because it can't be their responsibility to enforce the 
> testcase rule, but they would be forced to bear the consequences.
> 
> I would also like to posit that quite a number of bugs will then stay 
> RESOLVED indefinitely. If someone, say, fixes a bug on mn10200 or some 
> other obscure target, who's going to double-check after a release and put 
> in into CLOSED?

Yup.  Well, me, but other than that. :-)




More information about the Gcc mailing list