Checklist for a new major KDE release
-------------------------------------

- control:

  Verify that the depends, recommends and suggests are still accurate,
  and that any necessary replaces or conflicts have been added.

  Note that packages that have new khelpcenter docs should suggest
  khelpcenter and/or kde*-doc-html (I suggest both), so that users have
  some way of actually reading the docs.  I generally put a note in
  debian/*.README.Debian to this effect also (see below).

- copyright:

  There are two issues here: licenses and authors.

  The license audit is tedious.  The "licensecheck" script (shipped with
  kdesdk-scripts) is useful here (you can run it over source files to
  find which ones are obviously GPL, LGPL, BSD, etc).  Grepping for
  KAboutData::License in the source code can also save you some time
  (which would otherwise be spent opening and closing apps to look in
  the About box).

  The author audit is a little easier.  I tend to list primary authors
  by name, plus "and others" if appropriate.  Both AUTHORS files and the
  application's About box should be examined, since one or the other is
  often out of date.

- rules:

  Look for non-standard actions being taken in debian/rules (e.g.,
  moving things around, modifying or deleting files, etc).  Are these
  still necessary, or are they no longer relevant with the new upstream
  release?

- patches:

  Look over the patches in debian/patches that are currently being
  applied to the upstream sources.  Are these still necessary?  Are
  there new patches of a similar nature that need to be included?

- manpages:

  There are two issues here: out-of-date manpages and missing manpages.

  Are the existing manpages up-to-date?  Incorrect docs are often worse
  than no docs.  Things to check include:

  + command-line options specific to that app (try running app --help);
  + the list of upstream authors in the AUTHOR section (this is often
    easy since you can use the work you did for the copyright file);
  + related applications in the SEE ALSO section (sometimes new apps need
    to be added to this list);
  + khelpcenter documentation in the SEE ALSO section (there should be a
    pointer to the khelpcenter docs if the app actually has them);
  + and of course the date in the .TH heading, if you changed anything.

  Are there new applications that need manpages to be written?

  New manpages will often take some time, and I have uploaded packages
  with missing manpages before.  I would argue however that, at the
  very least, the existing manpages should be checked for correctness.

- menu files:

  Are there new applications that need new debian/*.menu files?  Are the
  existing *.menu files still accurate (specifically, in their title and
  longtitle)?

- XPM files:

  Are there new applications that need new XPM icons to be installed in
  /usr/share/pixmaps?  Are the existing XPM icons (debian/*.xpm) still
  correct, or have upstream changed their icons (which happens from time
  to time)?

- doc-base files:

  For the kde*-doc-html package, each application that ships HTML docs
  should also include a doc-base file.  Add any new doc-base files that
  are necessary, and check the existing doc-base files to ensure that
  the author, title and abstract are still correct.

- upstream docs:

  Upstream will often include random docs in their main directory
  (e.g., kdefoo/app/AUTHORS, kdefoo/app/README, etc).  Are the
  corresponding debian/*.docs files are up-to-date, or are there files
  that need to be added/removed?

- upstream changelogs:

  Are we installing the correct upstream changelogs?  Even within a
  single KDE module, some apps will ship CHANGES, some will ship
  ChangeLog and some will ship other variants on the name.  Some apps
  will ship two changelogs (one of which is current, one of which is
  not) and some apps will ship an empty changelog (which should not be
  installed).

- symbolic links:

  Verify that the symlinks installed by debian/*.links are up-to-date.
  Note that for every app with khelpcenter docs, I like to add

    /usr/share/doc/app/html -> ../kde/HTML/en/app

  so that people looking in the usual /usr/share/doc/app can find the
  real docs.  In my packages this doesn't show up in debian/*.links
  however, since it's done automatically from debian/rules.  I have no
  idea if/how the CDBS system deals with this.

- shlibs:

  For each package that installs shared libraries, look carefully over
  debian/*.shlibs to see if it needs updating.  For each debian/*.shlibs
  file in the old packaging, verify that the libraries it refers to
  still exist.

- overrides:

  Add any lintian / linda overrides for false or irrelevant warnings,
  and removing existing overrides that are no longer necessary.

- README.Debian:

  Are there any additional notes about the package that users should know?

  Note that, for every package that includes khelpcenter docs, I like to
  add a note here explaining how to read the docs.  If you're not a
  regular KDE user, this is not obvious.  I use something like the following:

    Quanta Plus provides documentation in a docbook format that the
    KDE Help Centre can display.  For HTML documentation that can be read
    in any web browser, see the package kdewebdev-doc-html.

-----

Ben Burton <bab@debian.org>, Sun,  6 Mar 2005 10:31:14 +1100