On Mon, 19 Jan 2009 20:54:04 +1100 Ben Finney <ben+debian@benfinney.id.au> wrote: > Neil Williams <codehelp@debian.org> writes: > > > The maintainer doesn't have to worry about -v [for > > ‘dpkg-genchanges’] - the sponsor does that with the final build that > > actually gets uploaded to Debian. > > Ah okay. I've never had a sponsor do that; following your advice with > multiple releases between actually-gets-to-Debian releases, I've only > ever seen the latest changelog entry in the upload. Take a look at some of the ACCEPTED messages for emdebian-tools - I use www.emdebian.org in the same manner as I require maintainers to use mentors.debian.net - I upload interim versions when Debian is in transition or in freeze. The interim versions, with all their bug closure entries, then get merged into a single .changes file (preserved within the ACCEPTED messages in the PTS) that covers all changes since the last version in Debian. OK, sometimes I forget but then it's my fault and my problem. Compare: http://packages.debian.org/changelogs/pool/main/e/emdebian-tools/current/changelog (the actual changelog, including all interim releases) and http://packages.qa.debian.org/e/emdebian-tools.html Possibly the clearest example is: http://packages.qa.debian.org/e/emdebian-tools/news/20080411T191703Z.html In general, emdebian-tools x.x.0 is a Debian upload (barring exceptions like RC bugs or urgent Debian fixes) and x.x.x is an Emdebian upload, so 1.3.0 went to Debian, 1.3.1 went to Emdebian whilst waiting for 1.3.0 to migrate into testing and 1.4.0 went back into Debian. The current release is 1.4.15 and the next Debian upload will be 1.5.0, including all the changes since 1.4.3. Outside a release freeze, I normally only have two or three interim releases during the time the package is waiting to migrate into testing. I generally make a release of emdebian-tools about three times a month - longer when larger transitions are occurring within the package (as is the case now). I have been known to make releases of emdebian-tools on four consecutive days, fixing different issues in different parts of the package. $ parsechangelog -v1.4.3|wc -l 340 :-) $ parsechangelog |wc -l 39 $ parsechangelog -v1.4.3|grep Closes Closes: 497816 498495 507285 507686 510521 512016 $ parsechangelog |grep Closes Closes: 512016 (Should have mentioned too, dpkg-buildpackage -v just passes the relevant version string to the underlying parsechangelog code that is then used by dpkg-genchanges to produce the .changes file. Whatever changelog you can generate with dpkg-buildpackage -v you can preview with parsechangelog -v). > What does this mean? Should I be refraining from your advice on > release number increments, or teaching my sponsors how to sponsor > better? It means that you follow the requirements of the sponsor who has agreed to review and upload the package. It's not up to anyone to "teach other sponsors", we have our preferred ways of working and our own reasons for those methods - typically around ensuring that sponsoring does not interrupt existing workflow patterns. (Sponsors have a lot of other stuff to do and there are many, many things in Debian where various DD's have significantly different ways of doing things.) Debian may seem to have a lot of standards and rules but there is a lot of variation in the areas where Policy allows choice. If your sponsor hasn't made it clear which methods and requirements they prefer, ask. I've tried to make my own criteria clear. (The page has been updated with the latest changes mentioned on the list today too.) -- Neil Williams ============= http://www.data-freedom.org/ http://www.nosoftwarepatents.com/ http://www.linux.codehelp.co.uk/
Attachment:
pgpZyneWmn5mR.pgp
Description: PGP signature