Re: PTS: RC bugs in dependencies
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
Reply to: