Re: Web part of bugzilla is ready (fwd)

[Christopher Faylor <cgf@redhat.com>]

Daniel,
I am not exactly sure need here but it sounds like what we need is:

1) Something to accept incoming, specially formatted email.

2) Something to generate email when a bug is entered in bugzilla.

Neither is hard to do.  I can set up 1 immediately, if you want.  We can
set up a gcc-bugzilla mailing list and have it go directly into your
database.  Just tell me what program needs to be run.

On the other side, I think that anything that shows up in bugzilla should
generate gcc-bugs email.  There's no reason to generate gcc-prs mail,
AFAICT.  You can do that now with no help from me, I think.

cgf

On Wed, Feb 05, 2003 at 07:31:22PM -0500, Daniel Berlin wrote:
>
>On Wednesday, February 5, 2003, at 03:04  AM, Jason Molenda wrote:
>
>>On Mon, Feb 03, 2003 at 11:36:13PM -0500, Christopher Faylor wrote:
>>>Ok, I did a little research.
>>
>>Sorry for not following up to this - I should have answered.
>>
>>
>>>>>1. I need to know how gcc-gnats actually works (IE the mail flow).
>>>>>To auto-parse incoming gnats reports, i need to feed the entire
>>>>>message
>>>>>into a perl script that has access to bugzilla.
>>>>>
>>>>>How does mail to gcc-gnats end up on gcc-bugs? (IE is it
>>>>>auto-mirroring in qmail, or is it done by a gnats handling script).
>>>
>>>There is a qmail alias set up which redirects mail delivered to
>>>gcc-gnats to a program (/usr/local/libexec/gnats/queue-pr) which
>>>eventually sends email to gcc-bugs and gcc-prs.
>>
>>Yeah, queue-pr (and gnatsd (gnatsweb)) save the incoming PRs as
>>plain text in a holding directory until a crontab runs (once every
>>ten minutes) to read in the newly-arrived PRs and put them in their
>>proper place under the proper uid.
>>
>>Specifically, /qmail/alias/.qmail-gcc-gnats contains
>>
>>|/sourceware/infra/bin/mlcheck --preferred-domain=gcc.gnu.org
>>|/qmail/bin/preline /usr/local/libexec/gnats/queue-pr 
>>--directory=/sourceware/gnats/gcc-db -q
>>
>>More than one program can be called out of .qmail-gcc-gnats, so if
>>you want to also get a copy of newly arriving gnats PRs, another
>>script can be handed them as they come in.  They don't yet have
>>their gnats #'s assigned, of course (you'd have to add a script to
>>the gcc-prs mailing list to see that).
>They don't need PR numbers, since they will be converted to bugzilla 
>bugs.
>IE when gcc moves over, we are not going to have it do insertion into 
>both databases, since gnats won't be used for gcc anymore. It will take 
>an incoming GNATS bug report, and insert it into bugzilla, not GNATS.
>
>>And you're running under
>>the one of the mail processing UIDs so you want to exercise some
>>security caution with what you plug in here.
>>
>
>Well, it *has* to have read access to bugzilla/ and bugzilla/data, and 
>write access to some temp dir (the mime decoder module wants this). But 
>all the *real* data goes into the mysql database.  It's perl, so buffer 
>overflows presumably won't be a concern.
>
>>>>>2. How does gcc-bugs email get appended to a bug?  For bugzilla, 
>>>>>it's,
>>>>>as one would imagine, a perl script that does it.
>>>
>>>I think that bug data is only appended when gcc-gnats is cc'ed.
>>
>>Yeah, e-mail messages being appended to a bug will come in through
>>gcc-gnats@gcc and they'll be added to the existing PR if their PR
>>category/# matches correctly.
>
>Through the same type of script process as new bug reports do?
>
>>
>>When a user changes the state of a PR or whatever through gnatsweb, a
>>notification is sent out to the gcc-prs list.  Note that nothing is
>>sent to gcc-gnats@, so if you just monitor gcc-gnats you'll only see
>>new PRs and PRs with e-mail additions, not state changes.  If you
>>monitor gcc-prs, you'll see new PRs, additions to PRs, and state
>>changes to PRs.  At least you _should_ see all those things. :-)
>>
>>
>>J