This is the mail archive of the libc-alpha@sources.redhat.com mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Using GCC Bugzilla for glibc


> Bugzilla has products and components. Presently, our only product is gcc, 
> glibc, binutils, and gdb would be other products. Within a product, there 
> are components; we have the C, C++, F77, ... frontends, middle-end, 
> optimization, ... components for gcc.

Ok.  We can figure out among the libc developers what components make sense
for us.  Most things are just "libc", but off hand I can imagine wanting
components: manual, faq, libc, linuxthreads, localedata, regex, nis.

> I beg to disagree. You are going to use the gcc.gnu.org domain, and we 
> care about the conduct of projects that want to use this domain. If glibc 
> or other projects are not making sure that bugs are handled, this will 
> lead to complaints also to the gcc lists and bugzilla maintainers.

We are obviously already closely cooperating projects with well-aligned
goals.  We would not be looking for a usable bug system if we did not want
to use it in fashion that makes it beneficial to maintenance efforts,
i.e. accurately reflects the state of development and gets reports actively
addressed.  However, we have do have quite different maintenance and
release procedures and independent schedules and milestones.  That is not
going to change per se, though alignment of planning between glibc, gcc,
and binutils work is always a good thing.  I do not foresee a problem in
practice--it's to everyone's benefit to use common conventions and stay in
touch; but we must be clear about the independence of decisions in glibc
procedures from those made by the GCC developers.

> Regarding policies: one of the arguments brought forward for a unified 
> database was that it is easier to move PRs from one product to another. 

That's a good point that I had not been thinking of.  It is certainly
common for gcc problems to be misreported as libc problems or vice versa
(and not rare for problems to authentically require some debugging before
the component at fault can be determined).  I am wholeheartedly in favor of
common conventions that ease the sharing and reassignment of bug reports. 


Thanks,
Roland


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]