Re: Future of gccbug

[Daniel Berlin <dberlin at dberlin dot org>]

> >
>
> I think, what you are asking for is not practical without adding full
> support for threaded replies to bugzilla itself.


> This would be nice
> (and has been implemented successfully in other "web discussion" media
> - see e.g. Slashdot nested mode) but would be a lot of work which I do
> not think it is fair to ask Daniel to do.

The pain of trying to shepard such a project through the bugzilla patch 
review process is enough to make me cringe at the thought.  It's not 
the coding work that bothers me, it's the fact that it woudl take a 
year at least to get it into the main bugzilla source, and we'd have 
*massive* code divergence problems until then (and even possibly 
after).

> An alternate idea, which also gets round the gcc-bugzilla/gcc-bugs
> headache: Have gcc-bugs be the primary, with messages sent directly
> there -- threading then Just Works.  gcc-bugzilla is a listener
> address subscribed to gcc-bugs; it watches all messages go by.  If
> they are properly tagged with a bug number, it adds them to the bug's
> disc

This is an option, of course, it will just require fooling bugzilla a 
little bit so that it thinks it's already sent mail out on these when 
it adds them to the database (or else it will resend the mail as a 
change reoprt when it receives it).
> Mail *is* sent to gcc-bugs when someone adds a comment to a bug via
> the web interface, but this mail has an X-header which tells
> the gcc-bugzilla listener to ignore it.

> zw