OoO En cette fin de matinée radieuse du samedi 25 octobre 2008, vers 11:07, Alexander Bürger <[EMAIL PROTECTED]> disait :
>> ... "Debian" changelog, not upstream ... > Hmm. I do not have an upstream changelog, and all previous > debian/changelog entries have the same problem. So what would you > suggest to do: > * Move all debian/changelog entries actually describing upstream changes > to a new upstream-changelog and replace it with "new upstream version" > for all upstream versions (0.1 -- 0.19) in debian/changelog? > * Keep the existing debian/changelog entries and start the upstream > changelog now? > And, as adding a new upstream changelog would mean that the orig.tar.gz > changes: > * Fix it in the next version (0.20) once there are upstream code > changes? > * Fix it now, keep version 0.19 and hide the new upstream changelog > until 0.20-1? > * Add the new upstream changelog via debian's diff.gz? That seems odd. > * Make 0.20 and 0.20-1. What would then be the upstream changelog > entry? No, no, you don't have to maintain yourself upstream changelog (you = as Debian package maintainer). I just point the fact that you put, in debian/changelog, an entry that looks like an upstream changelog entry. From a Debian point of view, the change is "New upstream release". This is not really important here since there is only on entry but if you add 3 features in the next version, you don't have to list them in debian/changelog. debian/changelog is the place to tell which bug is closed and what changes have happened in the packaging. >> ... currently in freeze... If there is an important problem ... >> ..0.18-1 .. in testing, it is easier to fix it if you can push the fix to >> unstable without pushing additional changes. Otherwise, it would have to >> be uploaded to testing-proposed-updates which causes more work for >> everybody and less possibilities of testing (no "grace" period to ensure >> that a few people test the package). >> >> However, the change is not very large (especially if we ignore >> indentation changes), so in case a fix needs to be pushed, maybe this >> new upstream version would be accepted as well. Therefore, it is up to >> you to upload to unstable (if you think that having a RC bug filed >> against fig2sxd is low probability and even if there is one, the current >> change is likely to be accepted) or to experimental. > Do you want to suggest making the same changes in diff.gz and call it > 0.18-2? Probably I do not understand what you actually ask here. No. I say that uploading in unstable a version that will never go in testing because of the freeze would put some difficulties on you if you need to upload a fix (a small fix that would be 0.18-2 for example). If you think that this fix is important enough to go in Lenny, you should ask on debian-release@ the permission to upload this new version and let it migrate to testing. Provide a debdiff (with -w in your case, otherwise, there is too much changes). -- I AM SO VERY TIRED I AM SO VERY TIRED I AM SO VERY TIRED -+- Bart Simpson on chalkboard in episode AABF20
pgp0xW7uMrpuX.pgp
Description: PGP signature
