Re: Reviving Debian QA
>>>>> "joey" == Martin Schulze <joey@finlandia.Infodrom.North.DE> writes:
joey> To be honest, there are still *lots* of packages not using all
joey> the suggested tools and integration (menu files, dwww files,
joey> doc-base files, alternatives, proper suggests/recommends, proper
joey> priorities etc.)
This is a nitpick, but actually, if you use doc-base, you never have
to use dwww.
joey> Now that several new maintainers mentioned QA or QA-like work in
joey> their new-maintainers application I'd like to invite people to
joey> work on QA for Debian. This doesn't need a fully fledged
joey> developer but also people who can only spend a few hours on
joey> Debian.
joey> I would appreciate if some people, both new and regular
joey> developers, would decide to work on QA for Debian GNU. Please
joey> look at the following - incomplete - list of things which fall
joey> into the field of duty for the QA team:
Honestly, I think the scope of the QA team is both too large and too
small.
joey> . Check old bugs - and work on them
joey> . Check packages with lots of bugs - and work on them
Any maintainer, or even non-maintainer, can do this.
joey> . Check if all packages providing user programs (X11 or not)
joey> come with menu files
joey> - Such packages have to call update-menus in their postinst
joey> and prerm scripts
This should simply be a lintian check, not a job for the manual
scrubbing of thousands of maintainer scripts.
joey> . Check if all packages that provide documentation register it
joey> for dwww, doc-base or whatever
Again, could easily be a lintian check. Less time consuming, and more
productive, IMHO.
joey> . Check if packages are policy conforming
Job for lintian and all users/developers in general (under the
heading, "File quality bug reports").
joey> . Add documentation where it is needed - there are lots of
joey> places where documentation is missing.
Job for the debian-doc team, unless you're talking about
debian-specific packages.
joey> . Detect orphaned packages and take care of them
Yes -- this should be the sole responsiblity of the QA team, IMHO.
joey> . Check if packages still work - especially old ones
Job for general user base, developer base, and the testing team.
joey> . Check if priorities, recommends, suggests and depends are
joey> used properly
Well, for one, this could be automated, cross-checking the override
file on the archive versus the advertised priority of the package --
we would need to start enforcing that people use 'dpkg-buildpackage
-isp', BTW; another lintian check!
joey> . Check if packages are linked against proper libraries, maybe
joey> check if they would work with newer stable ones (especially for
joey> Gtk-based programs) as well
joey> . Watch out for new versions of software and notify maintainers
joey> if needed.
Again, both of these are a job for general user base, developer base,
and the testing team.
Additional issue:
* check that patches that should be sent upstream are being sent
upstream -- I think this is very important and I think we have a
bit of a bad reputation on this count.
Conclusion:
I don't think we're going to ever have an effective single team
covering all these items. I don't think such a team will ever exist
because it's too large a scope of duties. I think we ought to:
(a) Debian QA's sole duty should be the maintenance of orphaned packages.
(b) dedicate some people to help Richard work on lintian. There are
many great suggestions here for as additions for lintian
functionality. So I think lintian could use both "feature
identification" help (I encourage anyone to file bugs -- I'll go thru
this list and file these) and "hacking source" help. I bet porters
could come up with some excellent ideas on potential lintian checks,
too.
(c) Perhaps implement a cron job check .dsc files (where priority and
section are exposed) and compare them to the override file, emailing
maintainers where they diverge, and possibly filing bug reports.
(d) Perhaps another cron job, implementing a public emailing to
debian-devel, listing the top 100 packages with huge debian diffs.
Start pushing harder for maintainers to try to work out fixes with
the upstream maintainers -- this is a cultural issue. (Maybe even a
lintian warning if the debian diff has lots of patches not under the
debian subdir?)
--
.....Adam Di Carlo....adam@onShore.com.....<URL:http://www.onShore.com/>
Reply to: