On Fri, May 10, 2013 at 10:03:57AM +0200, Raphael Hertzog wrote: > On Fri, 10 May 2013, Paul Wise wrote: > > I wonder if doing this recursively is a good idea or not. If we decide > > to do that, your approach to limit the recursion is a good one. > > I also tend to think that doing it recursively is not a good idea in > general. Or maybe only for packages which are not widely used
Not widely used could be measured with popcon. I'll keep this in mind. But I think that RC bugs in more popular packages deserve to be displayed on more PTS pages, not the opposite. > and are at risk of getting removed. How to measure that ? Anyhow, I've switched off the recursion for now, based on Zack's argument. > I would also suggest not displaying bugs where someone is actively taking > care of it (i.e. when a owner is set even though it's not often used). Creative idea, but I'm afraid that setting the owner is not a sufficiently common practice to base this on. > I would also suggest to completely ignore RC bugs in package with > lots of reverse dependencies, that is until they are tagged help > or are getting really old. I'm not sure about this. Somehow I think that RC bugs in packages with many reverse dependencies are more important than other. > > I think perhaps that limiting the amount of RC bugs filed against deps > > to 5 or 10 per PTS page would be good. > > While I understand the logic "too much and it's going to be > useless/ignored", I don't agree that we must put a hard limit. We might > have to tweak our rules to avoid too many such cases but then > once we have something it should be understandable and relatively > complete. I agree with trying to avoid such hard limit. Regards, Bart Martens -- To UNSUBSCRIBE, email to debian-qa-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130510132349.gc13...@master.debian.org