Re: Improvement of the QA pages.

[Andreas Tille <tillea@rki.de>]

[Debian-Custom in CC because this effort of Debian Med is of general
 interest regarding QA work inside our projects.]

Hi,

if you now look at

  http://qa.debian.org/developer.php?login=debian-med-packaging@lists.alioth.debian.org&ordering=3

you see (nearly - see below) the information which I would like to be viewed.
The script I used

   alioth:/srv/alioth.debian.org/chroot/home/groups/cdd/webtools/ddpo_register

does now regard the source packages over the binary packages which makes
much more sense on ddpo.

Here are some constraints:

  1. bio-dev beats bio:
     Even if bio is listed first the fact that emboss is subscribed to
     both bio and bio-dev leads to the effect that emboss is listed under
     bio-dev.  This is not nice esthetically.  I see 3 chances to handle
     this:

     1) Ignore it.  People who are interested in the biological part
        will parse both sections anyway.
     2) Saying this I wonder whether we should combine bio and bio-dev
        as well as imaging and imaging-dev because QA-wise it is the
        same target audience.
     3) Try to fix it - but I have neigher an idea how nor the effort
        this might cost.

  2. Implicite dependencies:
     There are some packages that are not mentioned explicitely in the
     tasks files becuase they depend from other packages mentioned in
     the task file and thus on installation time they are installed
     nicely - but on the QA pages they are not displayed in the right
     category.  I see also chances to handle this:

     1) Ignoring is not prefered here - it just looks ugly.
     2) Mentioning them in the tasks file with an extra field for
        instance "DDPO-Depends" and parse this field only for the
        ddpo issue, or rather find a more generic field name because
        we might need it later for other things as well.
     3) Try to parse the dependencies of the packages mentioned in
        the tasks files and mention them as well.  This would lead
        to the effect that some more packages will be listed in our
        sections which are not related to our work at all (for
        instance apache, postgresql, etc.) because several of our
        packages might need general dependencies.  What do you
        think about this.  Please think twice!  Somehow it is not
        really uninteresting to make sure that the dependencies are
        in good shape as well.  We might add a section
          <task>-dependencies
        for such kind of stuff.  But I'm really undecided about
        this and would like to hear your opinion.

  3. Sloppy maintainers ;-)
     Well, finally this is no constraint but an advantage: We see if
     maintainers did not care for including their packages in tasks
     file dependencies.  I blame for instance mafft uploaders and others
     for not keeping me informed that this is missing in the depends ...
     But now I'll catch you all if I see something mentioned in no
     specific section ... ;-))

Any comment is welcome

       Andreas.
--
http://fam-tille.de