This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Update on bugzilla stuff
- From: Daniel Berlin <dan at cgsoftware dot com>
- To: "Joseph S. Myers" <jsm28 at cam dot ac dot uk>
- Cc: <neil at gcc dot gnu dot org>, <gcc at gcc dot gnu dot org>
- Date: Tue, 1 Jan 2002 02:39:04 -0500 (EST)
- Subject: Update on bugzilla stuff
I removed the platform and os fields, fixed some other bugs/missing things
in conversion i noticed/you guys pointed out, and added the
host/build/target fields and extraction of them from the prs.
It also puts the environment field contents into a comment.
I had this done a week ago, but was out of town, and it's all on a new
machine (installed today), so i didn't get a chance to put it up till now.
The rest of the requests (changing severity/priority/state names/etc) are
minor things in terms of work on my part, so i'll concentrate on getting
the mail interface into shape.
The only catch is that if we keep both priority and severity, *and* add
class, then i'd have to re-layout the form to account for one new popup,
rather than just doing search/replace for either priority/severity.
Rather than list all the platforms from config.* in a popup where you see
host/build/target fields
(like the query page), i made them string search fields.
Thus, it's trivial to find all bug-reports against an i686 host, or a
linux target, for instance.
Attachments are compressed in the database (using Compress::Zlib, of
course), since most of the time they are huge preprocessed text files.
This trims the attachment database from 210 meg to 63.
This also prevents creating MySQL full-text search indexes (unless i
hacked mysql to handle searches on compressed text, which i'm not going
to), but i figured this was likely not going to be useful for attachments
anyway.
However, I have specifically *not* compressed the description texts for
this reason, so that database currently stands at 35 meg (14k records,
an average of roughly three per bug)
There is one bug report that was too large to insert into the
database without fiddling mysql parameters, which is 5154.
This happens because the file is not a real attachment, so it wants to
insert it as a comment. The query times out inserting 21 meg of
text. This is not a server or client bug, it just takes that long to
un-sql quote it,parse it, etc.
Right now I handle this bug report manually (the perl script doing
the conversion specifically skips it), since 8 bazillion pages of comment
text would be useless anyway.
The data in the bugzilla at http://www.dberlin.org/bugzilla-2.14 is
current as of this morning.
--Dan