[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/[EMAIL PROTECTED]&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 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
