Re: Verification of bug fixes

Hello Rodrigo,

On 2.10.2013 16:15, Rodrigo Rocha Gomes e Souza wrote:

[snip]

> Can we say that all or most fixes in High Resistance mode have the
> keyword *_HR_*, and all API changes have the keyword *API*?

Yes.

> If so, do you know since when the keywords are consistently used?

HR_FIX: since March 2011
API_REVIEW: since March 2004

[snip]

> * the fix to be reviewed is always submitted as an attachment in the bug report

Yes for API changes, not for bug fixes.

> * the bug is mark as FIXED only after it has been reviewed and committed to the hg repo.

Again, true for API changes but not true for bug fixes. Many bug fixes 
are not reviewed by anyone and once developer finds the cause and proper 
fix, s/he integrates it into the code repository and s/he changes the 
resolution to FIXED. Some bugs are even marked as FIXED without any 
commit. This happens when developer works on some older defect and 
realizes that the bug was already fixed but does neither remember when 
nor by which changeset etc.

[snip]

> So these bugs were reported because a test failed, right?

Yes.

> This is what the TEST keyword means, right? (that's what
> https://netbeans.org/bugzilla/describekeywords.cgi says)
> Can we say that all or most bugs reported because of failing tests have
> the TEST keyword?

Yes.

> Do you know since when is the TEST keyword consistently used?

Since July 2003.

> The bug reports were marked as REOPENED because of failing tests;

None of the two bugs was REOPENED. Both were filed as NEW, then FIXED 
and then VERIFIED.

> instead, they were reported because of them. If a failing test can be
> linked to a bad bug fix, what's the procedure? (a) the bug reported
> reopened, or (b) a new bug report is created?

I don't think we track anything like that. It would be too expensive.

Hope this helps,
-Jirka