I've recently noticed that several of our target libraries are not
properly (if at all) represented as bugzilla components. The following
table shows the current situation:
directory component
libada (ada)
libcpp (preprocessor)
libdecnumber
libffi libffi
libgcc
libgfortran libfortran
libgo (go)
libgomp libgomp
libiberty
libitm
libjava libgcj
libmudflap libmudflap
libobjc libobjc
libquadmath
libssp
libstdc++-v3 libstdc++
The entries in parens are only covered indirectly and may or may not
warrant their own components. I'd argue that it would be helpful to
have libada and libgo components of their own (while libcpp would
probably be overkill), but of course that's ultimately up to the
respective maintainers.
I think that at least some of the gaps need to be filled, notably libgcc
(recently bugs have been filed under other), libitm (new with the
trans-mem merge, but fits nowhere else) and libquadmath (it's not obvious
to a non-developer that bugs might perhaps be filed under libfortran).
I'm undeciced what to do about libdecnumber (primarily/exclusively from
upstream), libiberty (shared with src), and libssp (probably too
small/too little activity to warrant its own component).
Comments?
Rainer
--
-----------------------------------------------------------------------------
Rainer Orth, Center for Biotechnology, Bielefeld University
