Future of gccbug

[Zack Weinberg]

Gabriel Dos Reis <gdr@integrable-solutions.net> writes:

> Daniel Berlin <dberlin@dberlin.org> writes:
>
> | We don't actually track message ids of each sent out mail right now.
> | Even if we did, we don't know what comments are replies to other
> | comments, so it's not possible to do anything other than put them
> | under the first one.
>
> Precisely because you don't, it is  a pain to see which messages
> follow up to which messages.  One needs to connect to the bugzilla
> database to see a flat thread with "comment #foo". 
> Sending bugzilla mails thus seem to be useless.

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.

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
discussion trail, but does NOT send mail back to gcc-bugs having done
so.  Messages which are not properly tagged are trapped and held in
some sort of queue area; humans can go over these, and either figure
out which bug they belong to, or create new bug reports for them.

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