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'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


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