[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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

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.


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,

(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: