Re: Steering committee request regarding gcc's bugzilla

Re: Steering committee request regarding gcc's bugzilla

[Wolfgang Bangerth]

> Please allow gcc's bugzilla to also be used by binutils.  I think it
> makes sense to share the infrastructure as binutils and gcc are closely
> related.

I'm not quite sure whether this is a good idea. It seems to me as if the 
people presently working on bugzilla are no binutils experts, so what 
would be the benefit of having the two in the same data base? I've seen 
maybe 10 bugs (out of 13000) that turned out to be binutils bugs instead 
of gcc bugs. Why not set up a different bugzilla elsewhere? At least I'd 
like to see more convincing arguments why the two should reside in the 
same database.

W.

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

Re: Steering committee request regarding gcc's bugzilla

[Jakub Jelinek]

On Fri, Dec 12, 2003 at 03:14:36AM -0600, Wolfgang Bangerth wrote:
> 
> > Please allow gcc's bugzilla to also be used by binutils.  I think it
> > makes sense to share the infrastructure as binutils and gcc are closely
> > related.
> 
> I'm not quite sure whether this is a good idea. It seems to me as if the 
> people presently working on bugzilla are no binutils experts, so what 
> would be the benefit of having the two in the same data base? I've seen 
> maybe 10 bugs (out of 13000) that turned out to be binutils bugs instead 
> of gcc bugs. Why not set up a different bugzilla elsewhere? At least I'd 
> like to see more convincing arguments why the two should reside in the 
> same database.

Well, elsewhere would most probably mean on the same box.  binutils and
glibc CVS is on the same box as gcc CVS.

If we have 3 or 4 different databases (gcc, binutils, glibc, gdb?), then
I think it will mean more maintenance than sharing the same, just using
different components.

	Jakub

Re: Steering committee request regarding gcc's bugzilla

[Daniel Berlin]

On Dec 12, 2003, at 3:33 AM, Jakub Jelinek wrote:

> On Fri, Dec 12, 2003 at 03:14:36AM -0600, Wolfgang Bangerth wrote:
>>
>>> Please allow gcc's bugzilla to also be used by binutils.  I think it
>>> makes sense to share the infrastructure as binutils and gcc are 
>>> closely
>>> related.
>>
>> I'm not quite sure whether this is a good idea. It seems to me as if 
>> the
>> people presently working on bugzilla are no binutils experts, so what
>> would be the benefit of having the two in the same data base? I've 
>> seen
>> maybe 10 bugs (out of 13000) that turned out to be binutils bugs 
>> instead
>> of gcc bugs. Why not set up a different bugzilla elsewhere? At least 
>> I'd
>> like to see more convincing arguments why the two should reside in the
>> same database.
>
> Well, elsewhere would most probably mean on the same box.  binutils and
> glibc CVS is on the same box as gcc CVS.
>
> If we have 3 or 4 different databases (gcc, binutils, glibc, gdb?), 
> then
> I think it will mean more maintenance than sharing the same, just using
> different components.
>

Let's start with a question sure to be non-controversial: What the heck 
do i call it now that it's not just "GCC bugzilla" anymore.

IE instead of "GCC Bugzilla Main Page
 

This is GCC Bugzilla, the GCC bug tracking system."

what should it now say.


Please also note that all urls it puts in emails and whatnot will be 
http://gcc.gnu.org/bugzilla/<something>


There's only one urlbase, regardless of product, so unless we use one 
of gcc.gnu.org's other aliases, that's what the urls will be printed 
as.


(If i change the urlbase, it also invalidates all existing cookies, 
which people are using to change default columns listed on queries, 
etc).

Re: Steering committee request regarding gcc's bugzilla

[David Edelsohn]

>>>>> Daniel Berlin writes:

Daniel> Let's start with a question sure to be non-controversial: What the heck 
Daniel> do i call it now that it's not just "GCC bugzilla" anymore.

Daniel> IE instead of "GCC Bugzilla Main Page

Daniel> This is GCC Bugzilla, the GCC bug tracking system."

Daniel> what should it now say.

	GNU Toolchain Bugzilla?

David

Re: Steering committee request regarding gcc's bugzilla

[Carlo Wood]

On Fri, Dec 12, 2003 at 11:13:13AM -0500, Daniel Berlin wrote:
> Let's start with a question sure to be non-controversial: What the heck 
> do i call it now that it's not just "GCC bugzilla" anymore.
> 
> IE instead of "GCC Bugzilla Main Page
> This is GCC Bugzilla, the GCC bug tracking system."
> 
> what should it now say.

GCC And Binutils Bugzilla Main Page

This is GCC Bugzilla, the gcc and binutils bug tracking system.

-- 
Carlo Wood <carlo@alinoe.com>

Re: Steering committee request regarding gcc's bugzilla

[Daniel Jacobowitz]

On Fri, Dec 12, 2003 at 03:14:36AM -0600, Wolfgang Bangerth wrote:
> 
> > Please allow gcc's bugzilla to also be used by binutils.  I think it
> > makes sense to share the infrastructure as binutils and gcc are closely
> > related.
> 
> I'm not quite sure whether this is a good idea. It seems to me as if the 
> people presently working on bugzilla are no binutils experts, so what 
> would be the benefit of having the two in the same data base? I've seen 
> maybe 10 bugs (out of 13000) that turned out to be binutils bugs instead 
> of gcc bugs. Why not set up a different bugzilla elsewhere? At least I'd 
> like to see more convincing arguments why the two should reside in the 
> same database.

Personally, I agree with Wolfgang.  I don't think we'll need to move
back and forth between the DBs very often anyway.

I'm biased - I want one for GDB also, and I don't really want to
renumber all the existing GNATS PRs.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

Re: Steering committee request regarding gcc's bugzilla

[Joseph S. Myers]

On Fri, 12 Dec 2003, Daniel Berlin wrote:

> There's only one urlbase, regardless of product, so unless we use one 
> of gcc.gnu.org's other aliases, that's what the urls will be printed 
> as.

How hard would it be for different URLs to select different products and 
hide the components/versions/milestones for other products by default?

I.e., GCC and binutils have completely different version numbering
scehemes and components that make sense, so it would save some bug
reporter confusion if when reporting GCC bugs they only see possible
version/component values that make sense for GCC.  (But for the benefits
of a joint database to be there, it would need to be possible to move a
bug from the gcc to the binutils product and at the same time change GCC
version/component/milestone into binutils ones.)

-- 
Joseph S. Myers
jsm@polyomino.org.uk

Re: Steering committee request regarding gcc's bugzilla

[Gerald Pfeifer]

On Fri, 12 Dec 2003, Joseph S. Myers wrote:
> How hard would it be for different URLs to select different products and
> hide the components/versions/milestones for other products by default?

What's the benefit?

If it's really just 10 reports (a year?), not only is it not worth any
effort, I guarantee that overall maintainance and communications efforts
will increase.

Gerald

Re: Steering committee request regarding gcc's bugzilla

[Daniel Berlin]

On Dec 12, 2003, at 1:29 PM, Joseph S. Myers wrote:

> On Fri, 12 Dec 2003, Daniel Berlin wrote:
>
>> There's only one urlbase, regardless of product, so unless we use one
>> of gcc.gnu.org's other aliases, that's what the urls will be printed
>> as.
>
> How hard would it be for different URLs to select different products 
> and
> hide the components/versions/milestones for other products by default?
This is already done automatically.

> I.e., GCC and binutils have completely different version numbering
> scehemes and components that make sense, so it would save some bug
> reporter confusion if when reporting GCC bugs they only see possible
> version/component values that make sense for GCC.

This happens already in the select boxes.
When you select a product, it only shows version/components/target 
milestone that are available for that product.

"
[%# selectProduct reads the selection from f.product and updates
   # f.version, component and target_milestone accordingly.
"


>   (But for the benefits
> of a joint database to be there, it would need to be possible to move a
> bug from the gcc to the binutils product and at the same time change 
> GCC
> version/component/milestone into binutils ones.)
>

Re: Steering committee request regarding gcc's bugzilla

[Joel Sherrill]

Andreas Jaeger wrote:

>The glibc team also likes to move to GCC's bugzilla.  On behalf of the
>glibc team, I'd like to ask the GCC SC and bugzilla maintainers, to
>allow and enable this,
>
>Andreas
>  
>
 From a system administration standpoint, it makes sense to share the DB 
infrastructure and
share the sysadmin effort.  I hope it a problem for anyone else and the 
problems are just
technical details for making it work.  There is no point duplicating 
infrastructure and
maintenance effort if it can work and the machine can stand the extra load.

--joel

Re: Steering committee request regarding gcc's bugzilla

[Andreas Jaeger]

[-- Attachment #1: Type: text/plain, Size: 375 bytes --]


The glibc team also likes to move to GCC's bugzilla.  On behalf of the
glibc team, I'd like to ask the GCC SC and bugzilla maintainers, to
allow and enable this,

Andreas
-- 
 Andreas Jaeger, aj@suse.de, http://www.suse.de/~aj
  SuSE Linux AG, Deutschherrnstr. 15-19, 90429 Nürnberg, Germany
   GPG fingerprint = 93A3 365E CE47 B889 DF7F  FED1 389A 563C C272 A126

[-- Attachment #2: Type: application/pgp-signature, Size: 188 bytes --]

Re: Steering committee request regarding gcc's bugzilla

[Daniel Berlin]

On Dec 11, 2003, at 7:58 PM, Alan Modra wrote:

> I've mentioned this before on the gcc list, but didn't make a formal
> request to the gcc steering committee, so here goes:
>
> Please allow gcc's bugzilla to also be used by binutils.  I think it
> makes sense to share the infrastructure as binutils and gcc are closely
> related.  It will also be convenient when handling binutils bug-reports
> that are wrongly submitted as gcc bugs, or like the following PR that
> has a binutils dependency.

If you are willing to wait until i am finished with finals (the 21st), 
i can happily do this for you.
I just need to make some gcc-local things (like adding gcc-bugs to the 
cc list) that are currently unconditional, conditional on product==gcc.

If you want email followup capability, that'll require a few days too.
>
> On Thu, Dec 11, 2003 at 06:40:31PM +0000, wilson at tuliptree dot org 
> wrote:
>> There is no binutils bug db.  I will mention this to HJ, maybe he will
>> be interested in fixing the assembler bug.
>>
>> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=11999
>
> -- 
> Alan Modra
> IBM OzLabs - Linux Technology Centre

Steering committee request regarding gcc's bugzilla

[Alan Modra]

I've mentioned this before on the gcc list, but didn't make a formal
request to the gcc steering committee, so here goes:

Please allow gcc's bugzilla to also be used by binutils.  I think it
makes sense to share the infrastructure as binutils and gcc are closely
related.  It will also be convenient when handling binutils bug-reports
that are wrongly submitted as gcc bugs, or like the following PR that
has a binutils dependency.

On Thu, Dec 11, 2003 at 06:40:31PM +0000, wilson at tuliptree dot org wrote:
> There is no binutils bug db.  I will mention this to HJ, maybe he will
> be interested in fixing the assembler bug.
> 
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=11999

-- 
Alan Modra
IBM OzLabs - Linux Technology Centre