This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: Bugzilla'd version of our gnats database
- From: "Joseph S. Myers" <jsm28 at cam dot ac dot uk>
- To: Daniel Berlin <dan at cgsoftware dot com>
- Cc: <gcc at gcc dot gnu dot org>
- Date: Thu, 20 Dec 2001 19:54:52 +0000 (GMT)
- Subject: Re: Bugzilla'd version of our gnats database
On Thu, 20 Dec 2001, Daniel Berlin wrote:
> I've put up the current version (no attachments, no bug activity, and the
> users need to be pruned) at http://www.dberlin.org/bugzilla-2.14
The query form looks a complete mess in Lynx. It has a list of headings,
then a long list of values going under each heading:
Product: Component: Version: Target:
[ ] gcc
[ ] ada
[ ] bootstrap
...
[ ] web
[ ] 2.95
[ ] 2.95.2
[ ] 2.95.3
[ ] 2.96 (redhat)
[ ] 2.97 (redhat)
...
Status: Resolution: Severity: Priority: Hardware: OS:
[ ] UNCONFIRMED
[X] NEW
...
[ ] blocker
[ ] critical
...
The gnatsweb forms look fine in Lynx, which is what I normally use when
working with gnatsweb. The form should have each heading at the start of
the part of the form it relates to, rather than a list of headers then the
contents of all those headings.
Also, the default search should include UNCONFIRMED; RESOLVED, VERIFIED
and CLOSED statuses should probably be merged. This way, the default
search should include everything that hasn't been decided to be a
non-issue. Also, we should only ever use CLOSED for something we have
decided to be fixed, not a bug, or lacking enough information; as Neil
noted, "suspended" should not correspond to a CLOSED state; nor should
duplicate bugs be CLOSED unless also actually fixed. The GCC-specific
docs should make it clear. (I take it you can customise the docs, just as
the rest of the config.) As noted, I don't conside WONTFIX a good
resolution to have available. Again, "Hardware" and "OS", including lots
of systems not supported by GCC, need to change completely; and we should
distinguish those used by the reporter and those on which the bug has been
verified to occur as well.
The help file (http://www.dberlin.org/bugzilla-2.14/queryhelp.cgi)
contains a long list of the GCC categories, but with Product gcc listed on
the left for each, instead of the Component. The descriptions also ought
to be those from gnats.html. (Of course, when using Bugzilla for GCC, all
the customisations will need to be in CVS - accessible to everyone who can
currently write to wwwdocs, including but htdocs and cgi-bin.) Since just
below there's a list of components, we don't need both. But we don't need
the multiple copies present there of the list of components, either.
The docs for GCC will need to emphasise that we want bug reports via the
gccbug script if possible, rather than a web form, and don't expect users
to search for duplicates, just to submit the bugs using our instructions
in bugs.html. The link to the Mozilla bug reporting guidelines is
inappropriate for GCC - while we should link to the overall Bugzilla docs,
all the documentation at the GCC bug reporting site should be entirely
customised to how GCC uses the system.
--
Joseph S. Myers
jsm28@cam.ac.uk