Bug#736715: PTS shouldn't list packages under their maintainer in stable
Package: qa.debian.org
Severity: normal
It is confusing that pages like
http://qa.debian.org/developer.php?login=packages@qa.debian.org
list whoever maintained packages also under whoever is listed in
the maintainer field in stable - that person might have given up
maintainership of the package many years ago (or here in the case
of packages@qa.debian.org, it is no longer of any interest for QA
since it does now have a maintainer).
As an example, when looking for where a QA upload might make sense
for reducing differences with Ubuntu, I am not interested in seeing
the wmii package listed - that package is no longer maintained by QA.
I'd expect the maintainer in unstable to be the one and only being
responsible for all versions of the package.
When there are different maintainers in unstable and experimental,
I see the point of listing a package under both since it is not
trivial to see which maintainer information is more recent, and that
would usually anyway be resolved soon with a new upload.
Additional information from the discussion on #debian-qa :
12:33 < noshadow> looks like developer.php gets the information from database
files, so it looks more like a show or not show and no easy
graying out those where one is only maintainer in stable.
12:46 < noshadow> reading the source it looks like something in oldstable
should not show up. And if the examples I tried were correct
it indeed does not show up. So from the code it looks like it
was an explicit decision to have stable packages show up
there (but oldstable not).
12:49 < noshadow> stable stable-proposed-updates testing
testing-proposed-updates experimental and unstable are taken
for maintainer information while
oldstable{,/updates,-proposed-update} stable-updates
stable/updates testing/updates are not.
12:51 < noshadow> svn.debian.org/svn/qa/trunk date/ddpo/extract_archive.pl
line 139 the ', 1' part
12:52 < bunk> noshadow: IMHO unstable (and perhaps experimental) are the only
suites that make sense for checking maintainer information
12:54 < noshadow> bunk: I guess the interesting part in suggesting the change
is finding out what else used that maintainer information
from archive.db
Reply to: