Steve Langasek wrote: > What's hard to see at a glance is how large collections of packages are > interrelated in their dependencies. Many packages that you *don't* use > may be having a direct effect on the packages you *do* use as a result > of their bugginess. I'd like to be able to make as much of this > information as possible available to developers, so they can dig into > some of the larger package knots according to their interests rather > than it being exclusively the domain of the RM & assistants.
I'm interested in helping with this. My "why is X not in testing yet" script attempts to identify some hot spots, in the form of a few crude toplists: http://bjorn.haxx.se/debian/toplist.html http://bjorn.haxx.se/debian/stalls.html The first sorts packages according to which package has the highest number of other packages directly depend on it. Top-3: python2.3, kdelibs, qt-x11-free. The second sorts packages according to which package "stalls" the greatest number of other packages, via dependencies in more than one level. Top-3: python2.3, libxml2 and libxslt. I'd appreciate ideas and suggestions how to improve this and create other information digests that can help developers find and choose areas to work on. -- Björn