[Debian-med-packaging] Status of ball

Tue Aug 14 08:38:41 UTC 2012

Hi Andreas,

Thanks for your mail and the explanations. We are currently working on
untangling the patches, but it's pretty nontrivial. I hope we'll have a
better patch ready later today. The current commit was just to test if the
current version of BALL would compile on testing at all (which seems to
work). I did not upload it yet because (as you noticed) it merges a lot of
other stuff, too. I did not even want to push it, but as it seems, I
inadvertently did.

By the way, I am using pristine-tar on my machine, but I'll check if the
branch was not pushed for some reason. I'll also set the mailing list as
maintainer in the future.

Best,

Andreas

Am 14.08.12 09:15 schrieb "Andreas Tille" unter <andreas at an3as.eu>:

>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