Re: Update on bugzilla stuff

[Daniel Berlin <dan at cgsoftware dot com>]

On Tue, 1 Jan 2002, Joseph S. Myers wrote:

> On Tue, 1 Jan 2002, Daniel Berlin wrote:
> 
> > 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.
> 
> Suspended PRs are still mapping to RESOLVED/LATER - as Neil noted, this is 
> wrong, the status of such PRs should be something that does not indicate 
> them to be resolved, such as NEW/LATER, and which is found in the default 
> search parameters.
I plan on adding a suspended or something, this is a minor thing from a 
script perspective no matter how it's solved.

> 
> The search form still looks a mess in Lynx, with multiple fields (Product,
> Component, Version) having their values in a single vertical list with all
> the headings above that list.
This is hard to fix, because it would mean special casing lynx.
This is because it's a lynx problem, other text mode browsers like 
links/w3m lay it out fine.
I'm a text browser person too, and i stopped using lynx about a year ago.

> 
> The versions listed should distinguish 2.96 from 2.96 (redhat), and 
> probably 3.0-pre from 3.0.
Okey-dokey.

> 
> Some bug reports (e.g. 545) still get links such as "mailto:neil"; without
> an @gcc.gnu.org.  Also, that bug report has Reporter listed as 
> gnats@gcc.gnu.org, which is wrong.
Yes, i know, I just fixed it (i forgot to check the right place if we had 
a real mail address before defaulting to gnats@gcc.gnu.org)


> 
> > 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.
> 
> When we get attachments on new bugs going out by mail with the bug reports
> to gcc-bugs and gcc-prs (as well as new attachments on old bugs also going
> out by mail), small ones should probably be sent out as MIME text/plain
> attachments to the messages (if indeed plain text), larger ones compressed
> in mail.  That attachments aren't normally compressed is one of the
> problems with the current GNATS system.
Okeydokey.


> 
> > 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.
> 
> Making the comment text into an attachment manually in the conversion
> script for this PR is probably the appropriate solution.
If you think it's appropriate, i can make it so comments longer than x 
lines automatically become attachments rather than comments.
I just don't know what a good value for x is.

--Dan