Bug#978942: reportbug: Previously-filed WNPP bugs are not clearly identified
> I've noticed that when filing WNPP bugs for new packages, reportbug does not
> clearly identify if there is a previous WNPP bug for that (new) package.
> Instead, it seems to just return all WNPP bugs.
>
> Expected behavior:
> Debian packager files an ITP bug for foo. Packager forgets they have filed
> and later begins to file another ITP bug for foo. The reportbug program lists
> "1) #123456 ITP: foo -- package that does bar" as the first entry after
> querying the BTS.
>
> Actual behavior:
> The reportbug program lists all WNPP bugs. If the prior ITP for foo is present,
> it is many pages down and the packager is unlikely to see it.
>
> I have replicated this behavior with a few ITP/RFP bugs, but please let me
> know if you have any questions or issues with replicating. Thank you!
did you know you can filter the bugs list?
(2-62/6492) Is the bug you found listed above [y|N|b|m|r|q|s|f|e|?]? ?
y - Problem already reported; optionally add extra information.
N - (default) Problem not listed above; possibly check more (skip to Next page).
b - Open the complete bugs list in a web browser.
m - Get more information about a bug (you can also enter a number
without selecting "m" first).
r - Redisplay the last bugs shown.
q - I'm bored; quit please.
s - Skip remaining problems; file a new report immediately.
f - Filter bug list using a pattern.
e - Open the report using an e-mail client.
? - Display this help.
"f" in this menu, which you can access by typing "?" at the prompt. f.e.
(2-62/6492) Is the bug you found listed above [y|N|b|m|r|q|s|f|e|?]? f
Enter the search pattern (a Perl-compatible regular expression)
or press ENTER to exit: python
Bugs with severity normal: 69 reports (8 remain)
1) #516501 RFH: libapache2-mod-python -- Python-embedding module
for Apache 2
2) #623685 O: pygresql -- PostgreSQL module for Python
3) #677174 O: python-minimock -- simple library for Python mock objects
4) #816512 O: python-svg.path -- SVG path objects and parser for Python
...
it is probably preferable that the user is going to initiate the
search for a possible similar (or same package); the reason is that
there are several ways to call a source package (not to include
typos), with prefix/suffix for the programming language used and other
harmonization.
--
Sandro "morph" Tosi
My website: http://sandrotosi.me/
Me at Debian: http://wiki.debian.org/SandroTosi
Twitter: https://twitter.com/sandrotosi
Reply to: