[Debian-med-packaging] Mgltools are escaping our sentinel (Was: Bug#592417: marked as done)

[Andreas Tille]

Hi,

thanks to Steve we finally have a problem fixed which nearly had kicked
out a package out of Debian (see #605315).  At first thanks to Steve to
step in for the team.

On Mon, Dec 06, 2010 at 05:06:03AM +0000, Debian Bug Tracking System wrote:
> ...
> Maintainer: Debian Med Packaging Team <debian-med-packaging at lists.alioth.debian.org>
> Changed-By: Steve M. Robbins <smr at debian.org>
> Description: 
>  mgltools-utpackages - UT Austin software Python extensions
> Closes: 592417 605315
> Changes: 
>  mgltools-utpackages (1.5.4.cvs.20100912-1.1) unstable; urgency=low
>  .
>    * Non-Maintainer Upload.  Closes: #605315.
>  .
>    * setup.py: Apply patch from Tim Retout.  Closes: #592417.

I wonder how we can prevent such problems in the future.  IMHO one
problem is that all the mgltools packages are hidden from all our
sentinels because they are not mentioned in the tasks files.  I once
talked with Steffen about this but he thinks they should not be
mentioned there.  (I do not remember the reasons any more but I
remember that I was not convinced but trusted him as the maintainer
and user of these packages.)

I admit that I'm not really happy about the effect that these packages
somehow are escaping our QA tools and I'm wondering what we can do about
this.  Here are some options I would like to discuss:

  1. Include maintainer based information into sentinel:

     We could check what packages are maintained by
      <debian-med-packaging at lists.alioth.debian.org>
     and add these to a bug page.  The problem of this approach
     becomes obvious because there is no information *what* bug
     page should be used because we do not know to which task the
     package belongs.  Sometimes the team maintains pure non
     medical precondiction.  So IMHO this is not a good option.

  2. New field:

     Invent another field in the tasks pages which mentions those
     packages.  This would solve the categorisation issue.  However,
     it adds an extra level of complexity which I do not really like.
     I simply do not see a reason why a package which is intended
     to help biologists should not mentioned in a Recommends / Suggests
     level scheme.

  3. Use Enhances:

     This was just discussed on Debian Med list[1] and Debian Devel
     list[2] and is IMHO exactly what reflects the context of these
     packages and once this is used consistently we could adapt the
     bug pages according to the Enhances fields of they are really
     used as intended.

I would like to discuss means to enable us effectively watching our
packages and I wonder what method you would like to see implemented.  I
I have a clear preference for 3. because it fits the content and uses
uses an available (but rarely used and known) method.

Kind regards

        Andreas.

[1] http://lists.debian.org/debian-blends/2009/08/msg00024.html
    and following maisils in this thread
[2] http://lists.debian.org/debian-devel/2009/08/msg00644.html


-- 
http://fam-tille.de