On Mon, 2006-01-16 at 19:29 +0100, Erik Schanze wrote: > > Firstly, the changelog in indicates that the package is for the > > development version of gopchop, however, you should only upload > > stable releases to debian unstable (development/cvs/svn/etc releases > > generally go to experimental), > > Hehe, really? > # grep "^Version" /var/lib/apt/lists/ftp.de.debian.org_debian_dists_unstable_main_binary-i386_Packages |grep -i cvs|wc -l > 212 Disclaimer: What I've said below seems like common sense to me, but may be wrong/stupid/conservative/whatever. True, and at least one of those I maintain - mainly because it hasn't seen a release in ages, and I inherited the package from the previous maintainer, and I audited all the changes since the last package, and they were all bug fixes. You also missed the ones with SVN/TLA/etc in their version (a better test would be those that have a year in their version no). Packaging CVS snapshots can lead to the kind of situation we had with mod_perl (IIRC) in sarge, a pre-release was packaged for unstable, and it made it into sarge. Before upstream released it, they made some changes and now sarge's mod_perl (IIRC) is incompatible with the mod_perl used elsewhere. I'm probably remembering which package had the incompatibility wrong, it had something to do with apache/2 though. Basically it comes down to the probability of introducing bugs, incompatibilities or security problems versus the new features a release gives. For example, taking CVS/SVN snapshots of a post-release stabilisation branch is always good, usually those contain only bug fixes, but packaging gnome 2.13 or linux 2.5 probably isn't a good idea. So, in my opinion, if you are packaging stuff that should not be in a stable release, upload to experimental, or at the very least add a blocking bug to it so it doesn't migrate to testing. I also see a lot of uploads to experimental for new upstream stable releases, and then calls for testing on debian-devel. John, as part of upstream of gopchop, you are in the best position to decide which way to go with this, so if you are comfortable with 1.1.7 being used by users for the expected 1.5-2 years of etch's lifetime (assuming the same expected life as sarge), by all means get it uploaded to unstable. -- bye, pabs http://wiki.debian.org/PaulWise
Attachment:
signature.asc
Description: This is a digitally signed message part