[Debian-med-packaging] Status of ball

[Andreas Tille]

Hi Andreas,

to some extend by chance I stumbled upon bug #674226 and I'm a bit
unsure how to proceed.  My wording "by chance" is that I was poking in
the list of Debian RC bugs to speed up the release a bit in general to
shorten the release cycle and enable the Debian Med team to do some even
more exciting stuff for the next release.  I went to the general list of
bugs because I assumed we have done all relevant Debian Med RC bugs now.

Unfortunately this was obviosely not true because the RC bug in ball was
somehow hidden because it does not follow or policy[1] and set the
mailing list as maintainer and so the problem did not showed up on our
bug list[2].  So I wonder whether somebody has introduced you into the
advantages you might gain when joining the Debian Med team a bit closer
and using the resources Debian might provide a bit more effectively.

I know you are maintaining the ball packag in Debian Med Git repository.
Unfortunately this repository does not really follow our rules featuring
a branch which lets pristine-tar recreate the orig.tar.gz file and thus
does not enable building by using git-buildpackage.

Inside the Git repository I found some changelog entry saying:


ball (1.4.1+20111206-3.1) unstable; urgency=low

  * Non-maintainer upload.
  * Merged many upstream fixes that will be part of BALL 1.4.2
  * Should fix compile problems with newer g++

 -- Andreas Hildebrandt <andreas.hildebrandt at uni-mainz.de>  Sun, 12 Aug 2012 23:45:39 +0200


This entry triggers several questions:

  1. Why is this a Non-maintainer upload?
  2. If target distribution is set to "unstable" is the package
     actually uploaded or not (or group policy[1] says you should
     set UNRELEASED to make this clear)
     I can not see any sign for an upload (if the maintainer
     field would have been set to the mailing list this question
     would not occure.)  Did you asked for sponsering?
  3. What means "should" fix compile problems with newer g++ ?
     Does it close the bug or not and if yes, why is the closes
     statement missing
  4. If the upload should close the bug in testing which is currently
     frozen you should fix only those problems that are relevant for
     problems which are reported as release critical bugs.  So things
     like "Merged many upstream fixes ..." are really problematic
     because the release team will most probably refuse to take over
     this package and will rather kick ball out of the next release.

So how to we want to proceede from here?  My suggestion is twofold for
the different states of release

  I. For the currently frozen package:
     We need to provide a *simple* patch addressing the gcc++
     problem and we probably should do this using quilt by doing
     a minimum of changes to the latest uploaded version.  Could
     you provide such a simple patch?  Please also foreward this
     patch to the bug address to keep other bug hunters informed
     that the issue is dealt with.

     I would volunteer to sponsor this patched package to fix the
     bug.

 II. For the future:
     Provided that you agree to follow the Debian Med policy we should
     make the Git archive conform to our rules.  IMHO it does not help  
     to have a simple clone of your upstream development repository
     (other team members might see this differently) and I would rather
     prefer if only released versions would be imported using
     pristine-tar (see [1]).  If you insist in having the fill upstream
     history this is fine but we should get a working pristine-tar
     branch in addition.  Our Git experts will probably help you in
     creating this.
     Moreover we should follow the usual team maintenance rules in
     our policy[1] and I would recommend you should become more verbose
     on our mailing lists about sponsoring requests and possibly other
     issues we might discuss in public.

Kind regards

       Andreas.

PS: Steffen, your remark in BTS from
    Date: Tue, 29 May 2012 18:22:14 +0200
    in the BTS is quite useless.  What should this tell the reader of
    the bug report?  It would have been more helpful if you would
    have introduced Andreas more deeply into the rules inside our
    team and the general rules in Freeze time.

[1] http://debian-med.alioth.debian.org/docs/policy.html
[2] http://bugs.debian.org/debian-med-packaging@lists.alioth.debian.org

-- 
http://fam-tille.de