(Adding debian-qa@ to Cc to broaden the discussion a bit) Hi,
On the issue of lintian.d.n/lintian.d.o/UDD/tracker.d.o, I wonder if the separation of concerns is the right one. I think that in Debian, we would aim for a better separation between: A/ QA tools development, focused on getting the good tools to analyze packages (output: tools, as Debian packages) B/ infrastructure that mass-process the archive using QA tools. (output: current status of each package in Debian, analyzed with the latest version of a given tool, as a parsable file) C/ infrastructure that gathers the current status from all instances of (B) and exposes it per-package, per-maintainer, per-team, etc. (C) could even be split into: (C.1) infrastructure that gathers the status and stores it into a common DB; (C.2) infrastructure that uses (C.1) to provide useful per-package/per-maintainer frontends (views). lintian.d.n is again an attempt at solving (B) and (C) at the same time. While I don't want to prevent anyone from working on their projects of choice, I wonder if someone else shouldn't work on a 'lintian archive runner' service whose sole mission would be to provide the current status of the archive against the current version of lintian as something parsable, just to feed UDD/tracker/others. Lucas
