Re: PTS: RC bugs in dependencies
On Fri, May 10, 2013 at 02:24:56PM +0800, Paul Wise wrote:
> On Fri, May 10, 2013 at 2:03 PM, Bart Martens wrote:
> > There are RC bugs in dependencies : #579647 #545414 #658739 #566351 #368297 #601667 #658896 #628671
>
> Several of these bugs are merged, I think we should only link to one
> of the merged bugs.
Good point. I have now modified the script accordingly.
> 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.
Limiting the recursion is a compromise. Zack convinced me to drop the
recursion (at least for now).
> I guess you focused on bugs tagged 'help' so that less maintainers are
> affected?
To start with a small sample. Also, I think that some RC bugs are easy to fix,
so don't need advertising on so many PTS pages. For example, some FTBFS bugs
can be quite easy to fix. Now, where to draw the line. Bugs tagged "help" are
bugs for which the package maintainer explicitly asks for help, so there's an
objective reason to advertise them on reverse dependencies PTS pages.
> Is the result very different if you change that to all RC
> bugs?
To my surprise the ratio for all RC bugs is also quite reasonable :
- with tag "help" : 12/312 http://qa.debian.org/~bartm/depneedshelp/depneedshelp_tagged_help.txt
- all RC bugs : 1133/12298 http://qa.debian.org/~bartm/depneedshelp/depneedshelp_all_rc.txt
I've kept the number 150 at that for now, and I've not yet tried sufficient
other numbers to draw conclusions on that.
> Perhaps we could use recursion for bugs tagged 'help' and no
> recursion for RC bugs older than one month.
I would rather choose the reverse : to advertise older bugs on more PTS pages,
since these are bugs that are apparently difficult to fix by the people already
looking at them. Why would you advertise older bugs on less PTS pages ?
> A blacklist may be needed to avoid things like eglibc appearing on all
> packages containing ELF binaries though.
If somehow possible I would prefer to not introduce a blacklist, because it
needs maintenance by someone judging which packages to put on the list. An
algorithm like I'm using now with that number 150 feels more dynamic to me, as
packages can fall in/out the selection over time without human intervention.
> It is my feeling that bugs tagged 'help', especially in core packages,
> are probably ones that are harder to fix
I agree with that.
> and may not be good targets for getting people who aren't intimately familiar
> with the packages to fix them.
This is somewhat the same argument as Zack's against using recursion. I guess
the package maintainers of one level of reverse dependency should be
sufficiently familiar with the RC buggy packages to give fixing the RC bugs a
try.
> I think perhaps that limiting the amount of RC bugs filed against deps
> to 5 or 10 per PTS page would be good.
That's a limitation I hadn't thought of yet. Maybe it's not a problem. I see
just libreoffice and meta-gnome3 with slightly more bugs than 10.
http://qa.debian.org/~bartm/depneedshelp/depneedshelp_all_rc.txt
Regards,
Bart Martens
Reply to: