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


> 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.

Yes, these seem sensible categories. It's easy for a maintainer to add 
components, btw, and those of you regularly working with bugzilla will all 
be maintainers. So if you find the need to add a components, that's 
simple, you don't have to know already now.


> > 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.

Yes, that is absolutely understood, and we certainly do not intend to 
restrict your freedom in any of the cases you mention. Our only concern is 
that gcc will get the blame if other projects using gcc.gnu.org don't 
process the bug reports that get filed for them. I'm very positive we can 
sort out any problems that arise. I should mention that us gcc bugzilla 
maintainers usually discuss questions of procedures and similar things on 
a private mailing list, bugzilla-masters@dberlin.org. 

Daniel, I forgot the address where one can subscribe -- would mind making 
this available to the ones involved from the glibc side?


> 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

It does happen, but is rarer than one might think (I can think of less 
than a dozen cases in gcc bugzilla).

> (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. 

It's this, and sharing our experiences with running a bug database. It 
took us a while to tweak our procedures and conventions so that things 
work smoothly, and we'd be happy to share what we learned if you're happy 
to accept what we found is working and what is not.

W.

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




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