This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

getting better info out of Bugzilla


RMS has been bugging the Steering Committee about the the bug backlog; he
is worried about its size.  In trying to put together some answers for
him, I was struggling with the fact that it is very difficult to tell,
with four open lines of development (4.0, 4.1, 4.2, 4.3), which bugs are
in which versions, and to distinguish shipping bugs from development bugs.
For any individual bug, you can usually tell by reading the entire
Bugzilla history, but this isn't feasible when dealing with several

We actually have fields that are supposed to answer this question:
"Known to Fail" and "Known to Work".  However, these fields are not
being set in a consistent manner, and aren't being updated when the
situation changes.

I'd like to get to the point where I can quickly get an answer to
questions like "How many P1 bugs affect gcc-4.1.1".  I think the cleanest
way to do that is to at least have correct Known to work/fail status for
the most serious bugs, for the most recent release (ideally all release
branches as well).  It will be a big job to clean this up, but I'd like to
ask maintainers to try to remember to update these fields when a bug is
fixed on a given branch.  Also, when reviewing the status of a given bug,
if you can make Known to work/Known to fail more accurate, please do.

Because there are so many open bugs, it's probably best to start with the
P1 bugs.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]