public inbox for gcc@gcc.gnu.org
 help / color / mirror / Atom feed
* Parsing mail to Bugzilla
@ 2003-03-25 21:15 Wolfgang Bangerth
  2003-03-25 21:24 ` Daniel Berlin
  0 siblings, 1 reply; 6+ messages in thread
From: Wolfgang Bangerth @ 2003-03-25 21:15 UTC (permalink / raw)
  To: gcc, dberlin


Dan,
one more thought: when one sends mail to gnats or bugzilla with a subject 
of <component>/<number>, can you make sure that the mail is appended to 
the right report even if the component does not match that of the report? 
The component is changed sometimes, while the number is not, so what used 
to be c++/1234 might become optimization/1234, but we would like to get 
mail with both strings in the subject line be appended to the right PR. I 
don't know whether GNATS does that, but it would be nice if Bugzilla just 
checked that <component> is something known, but not verify it against the 
component of the particular PR.

If this hasn't been decided: I'm in favor of shutting down gnats, 
converting the database, then bringing up bugzilla. There is no value in 
the complexities of running them both at the same time and trying to synch 
them afterwards.

Thanks
  W.

-------------------------------------------------------------------------
Wolfgang Bangerth             email:            bangerth@ticam.utexas.edu
                              www: http://www.ticam.utexas.edu/~bangerth/


^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: Parsing mail to Bugzilla
  2003-03-25 21:15 Parsing mail to Bugzilla Wolfgang Bangerth
@ 2003-03-25 21:24 ` Daniel Berlin
  2003-03-25 21:43   ` Tom Tromey
  0 siblings, 1 reply; 6+ messages in thread
From: Daniel Berlin @ 2003-03-25 21:24 UTC (permalink / raw)
  To: Wolfgang Bangerth; +Cc: gcc


On Tuesday, March 25, 2003, at 03:57  PM, Wolfgang Bangerth wrote:

>
> Dan,
> one more thought: when one sends mail to gnats or bugzilla with a  
> subject
> of <component>/<number>, can you make sure that the mail is appended to
> the right report even if the component does not match that of the  
> report?

It does.

Number is unique in bugzilla.
It ignores component when parsing.

>
> The component is changed sometimes, while the number is not, so what  
> used
> to be c++/1234 might become optimization/1234, but we would like to get
> mail with both strings in the subject line be appended to the right  
> PR. I
> don't know whether GNATS does that, but it would be nice if Bugzilla  
> just
> checked that <component> is something known, but not verify it against  
> the
> component of the particular PR.
>
> If this hasn't been decided: I'm in favor of shutting down gnats,
> converting the database, then bringing up bugzilla. There is no value  
> in
> the complexities of running them both at the same time and trying to  
> synch
> them afterwards.
>
> Thanks
>   W.
>
> ----------------------------------------------------------------------- 
> --
> Wolfgang Bangerth             email:             
> bangerth@ticam.utexas.edu
>                               www:  
> http://www.ticam.utexas.edu/~bangerth/
>
>

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: Parsing mail to Bugzilla
  2003-03-25 21:24 ` Daniel Berlin
@ 2003-03-25 21:43   ` Tom Tromey
  2003-03-25 22:04     ` Daniel Berlin
  0 siblings, 1 reply; 6+ messages in thread
From: Tom Tromey @ 2003-03-25 21:43 UTC (permalink / raw)
  To: Daniel Berlin; +Cc: gcc

>>>>> "Dan" == Daniel Berlin <dberlin@dberlin.org> writes:

Dan> Number is unique in bugzilla.
Dan> It ignores component when parsing.

I think it would make sense to loosen the allowed formats for
mentioning a bug in a commit message.  Doesn't bugzilla parse the text
of bug entries, looking for references to other bugs?  Perhaps we
could allow all those styles as well.

Tom

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: Parsing mail to Bugzilla
  2003-03-25 21:43   ` Tom Tromey
@ 2003-03-25 22:04     ` Daniel Berlin
  2003-03-25 22:23       ` Daniel Jacobowitz
  0 siblings, 1 reply; 6+ messages in thread
From: Daniel Berlin @ 2003-03-25 22:04 UTC (permalink / raw)
  To: tromey; +Cc: gcc


On Tuesday, March 25, 2003, at 04:23  PM, Tom Tromey wrote:
>
>>>>>> "Dan" == Daniel Berlin <dberlin@dberlin.org> writes:
>
> Dan> Number is unique in bugzilla.
> Dan> It ignores component when parsing.
>
> I think it would make sense to loosen the allowed formats for
> mentioning a bug in a commit message.

My current log_accum (and bugzilla followup handler, though without the 
last little bit since it has no log message to deal with in a subject) 
regex looks like:
m/(?:Bug|PR)(?:\s*)(?:[a-z]+\/)?([\d]+).*/si

IE it can handle Bug|PR <any amount of space> <optional word 
prefix+/><number><rest of log message>, case insensitively.


The only thing it verifies is that the bug id matches the product 
passed to log_accum IE that bug <number> is really for product 
<whatever was passed on the command line>.
This was done so that if other projects want to use bugzilla, their 
log_accum won't pick up non-project bugs accidently in commit messages.

Though this might make sense anyway, thinking more about it (this would 
mean that if gdb switched to bugzilla, and a gdb commit mentioned a gcc 
bug, or a gcc commit mentioned a gdb bug, the bug would get a comment 
appended about the commit).
T
> Doesn't bugzilla parse the text
> of bug entries, looking for references to other bugs?
Yes. Not just references to other bugs, but references to attachments 
in other bugs, comments in other bugs (IE you can directly link to a 
comment in another bug), etc.

This is done in bugzilla's bug display stuff, not log_accum's "is this 
for a bug" time.

>  Perhaps we
> could allow all those styles as well.
>
> Tom

> Tom

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: Parsing mail to Bugzilla
  2003-03-25 22:04     ` Daniel Berlin
@ 2003-03-25 22:23       ` Daniel Jacobowitz
  2003-03-25 23:06         ` Daniel Berlin
  0 siblings, 1 reply; 6+ messages in thread
From: Daniel Jacobowitz @ 2003-03-25 22:23 UTC (permalink / raw)
  To: Daniel Berlin; +Cc: tromey, gcc

On Tue, Mar 25, 2003 at 04:55:13PM -0500, Daniel Berlin wrote:
> 
> On Tuesday, March 25, 2003, at 04:23  PM, Tom Tromey wrote:
> >
> >>>>>>"Dan" == Daniel Berlin <dberlin@dberlin.org> writes:
> >
> >Dan> Number is unique in bugzilla.
> >Dan> It ignores component when parsing.
> >
> >I think it would make sense to loosen the allowed formats for
> >mentioning a bug in a commit message.
> 
> My current log_accum (and bugzilla followup handler, though without the 
> last little bit since it has no log message to deal with in a subject) 
> regex looks like:
> m/(?:Bug|PR)(?:\s*)(?:[a-z]+\/)?([\d]+).*/si
> 
> IE it can handle Bug|PR <any amount of space> <optional word 
> prefix+/><number><rest of log message>, case insensitively.
> 
> 
> The only thing it verifies is that the bug id matches the product 
> passed to log_accum IE that bug <number> is really for product 
> <whatever was passed on the command line>.
> This was done so that if other projects want to use bugzilla, their 
> log_accum won't pick up non-project bugs accidently in commit messages.
> 
> Though this might make sense anyway, thinking more about it (this would 
> mean that if gdb switched to bugzilla, and a gdb commit mentioned a gcc 
> bug, or a gcc commit mentioned a gdb bug, the bug would get a comment 
> appended about the commit).

Bug ID is unique across products in Bugzilla isn't it?  So wouldn't
anything with a separate GNATS database have to have a separate
Bugzilla setup (or accept bugs to be renumbered)?

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: Parsing mail to Bugzilla
  2003-03-25 22:23       ` Daniel Jacobowitz
@ 2003-03-25 23:06         ` Daniel Berlin
  0 siblings, 0 replies; 6+ messages in thread
From: Daniel Berlin @ 2003-03-25 23:06 UTC (permalink / raw)
  To: Daniel Jacobowitz; +Cc: tromey, gcc


On Tuesday, March 25, 2003, at 05:04  PM, Daniel Jacobowitz wrote:

> On Tue, Mar 25, 2003 at 04:55:13PM -0500, Daniel Berlin wrote:
>>
>> On Tuesday, March 25, 2003, at 04:23  PM, Tom Tromey wrote:
>>>
>>>>>>>> "Dan" == Daniel Berlin <dberlin@dberlin.org> writes:
>>>
>>> Dan> Number is unique in bugzilla.
>>> Dan> It ignores component when parsing.
>>>
>>> I think it would make sense to loosen the allowed formats for
>>> mentioning a bug in a commit message.
>>
>> My current log_accum (and bugzilla followup handler, though without 
>> the
>> last little bit since it has no log message to deal with in a subject)
>> regex looks like:
>> m/(?:Bug|PR)(?:\s*)(?:[a-z]+\/)?([\d]+).*/si
>>
>> IE it can handle Bug|PR <any amount of space> <optional word
>> prefix+/><number><rest of log message>, case insensitively.
>>
>>
>> The only thing it verifies is that the bug id matches the product
>> passed to log_accum IE that bug <number> is really for product
>> <whatever was passed on the command line>.
>> This was done so that if other projects want to use bugzilla, their
>> log_accum won't pick up non-project bugs accidently in commit 
>> messages.
>>
>> Though this might make sense anyway, thinking more about it (this 
>> would
>> mean that if gdb switched to bugzilla, and a gdb commit mentioned a 
>> gcc
>> bug, or a gcc commit mentioned a gdb bug, the bug would get a comment
>> appended about the commit).
>
> Bug ID is unique across products in Bugzilla isn't it?
Yes
>   So wouldn't
> anything with a separate GNATS database have to have a separate
> Bugzilla setup (or accept bugs to be renumbered)?

Yes.
--Dan

^ permalink raw reply	[flat|nested] 6+ messages in thread

end of thread, other threads:[~2003-03-25 22:25 UTC | newest]

Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2003-03-25 21:15 Parsing mail to Bugzilla Wolfgang Bangerth
2003-03-25 21:24 ` Daniel Berlin
2003-03-25 21:43   ` Tom Tromey
2003-03-25 22:04     ` Daniel Berlin
2003-03-25 22:23       ` Daniel Jacobowitz
2003-03-25 23:06         ` Daniel Berlin

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).