Re: Improvement of the QA pages.
[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
Reply to: