Re: Packages preventing other packages from going into testing
On Tuesday 17 June 2003 11.30, Riku Voipio wrote:
> On Sun, Jun 15, 2003 at 06:44:12PM +0200, Jacob Hallén wrote:
> > Essentially, it is a count of packages that directly and indirectly
> > depend on a package with at least one RC bug before they can go into
> > testing.
> >
> > My idea is to show where the low hanging fruits are, so that people able
> > to lend a hand know where to go.
>
> While this is very nifty, unfortunatly just counting RC bugs doesn't
> track where real effort is needed.
>
> Take kdelibs as an example. When the RC bugs for kdelibs are fixed,
> kdelibs still can't goto testing, because all other kde applications
> have to be RC free and compile on all supported platforms. And since
> kdebase is creating internal compile errors from gcc-3.3 on
> mips/mipsel[1], there is not much sense raping buildd machines with
> builds that are bound to fail on some archs. And alas, there is not
> much one can do to fix gcc ICE bugs without knowledge of gcc internals.
>
> [1] 'http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=194330'
Your reasoning has a lot of merit, but doesn't contradict mine.
Let's for a moment assume that all the gcc-3.3 errors in KDE were solved.
KDE would still be held up by the RC bug in openldap2, along with some 30 odd
other packages.
If on the other hand, the openldap2 bug was solved, the gcc-3.3 errors would
surface as the remaining problem for KDE. I think that the KDE maintainers
would feel more strongly motivated to put efforts into solving these
problems, once they know that the transition into Testing is in their own
hands. Otherwise, they would probably spend their time on working on other
packages, debating how to handle spam or anything that would feel more
rewarding at the time.
Jacob Hallén
Reply to: