This is the mail archive of the gcc@gcc.gnu.org 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]

Re: Bugzilla for GCC project?


On Mon, 27 Jan 2003, Daniel Berlin wrote:

> If you want to see the current bugzilla, it's at 
> http://www.dberlin.org/bugzilla-2.17.3/

It generally looks fine (and looks better with Lynx than some older
Bugzilla versions - except Lynx complains "Accept invalid cookie
path=/bugzilla-2.17.3/ as a prefix of '/bugzilla-2.17.3'" about it, I
don't know what this is a bug in; GNATSweb also used to have such a
problem, which got fixed).


Residual conversion issues (losing information in the conversion, so 
preferably to be resolved before transition - though as previously 
discussed GNATS is also losing information as long as it runs, the MIME 
headers on messages people send to PRs):

* The full version number string (with the exact compiler date) is still
getting lost in the conversion.  (The specific version numbers listed are
also missing numbers used for head-of-release-branch bug reports - 2.95.4,
3.0.5, 3.1.2, 3.2.2 - as well as 2.95.1.)

* "feedback" PRs show up as RESOLVED/FIXED.  They clearly aren't resolved,
though in the absence of feedback they'll get closed eventually as INVALID
/ WORKSFORME.

* Do people think the information in "Class" (doc-bug, ice-on-legal-code,
...) is useful?  (I don't care much about it, but perhaps it should end up
as a keyword in the new database or something.)


Conversion issues that can be dealt with afterwards but shouldn't be
forgotten (bugs can always be opened in the new database to track them):

+ "suspended" PRs show up as RESOLVED/LATER which means they don't appear
in default searches, even though they are logically open bugs.  Past
discussion suggests they should be kept open but the information about why
they are suspended be kept in other fields, e.g. dependencies.  (Though
the bug I opened for suspended C++ parser bugs to depend on, in the
expectation this transition would be done before the new parser, has been
fixed by the new parser.)

+ What's the logic in which bugs show up as RESOLVED, and which as CLOSED,
and is the distinction useful?  (None show up as VERIFIED, so we probably
don't need that status.)

-- 
Joseph S. Myers
jsm28@cam.ac.uk


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