Hi, > ... "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? > ... 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. For some people who want to convert huge polylines (the one in the bug report had > 5500 points) it is certainly helpful -- without, the program output is correct but unusable. The problem is caused by a bug in OOo (their bug #95095) which makes OOo read some files generated by fig2sxd (or whatever other program producing OOo files) incorrectly. The ideal solution would be to fix the OOo problem and stay with fig2sxd 0.18. Otherwise I think 0.19 should be used in testing, but I do not expect that this is fast (that's also why I implemented the workaround). It will continue to work the OOo problem is fixed, and I would not like to have the program with a known problem in a stable release. As you say, the actual changes between 0.18 and 0.19 are minor. I could also make 0.20, where I would fix the changelog problem and add a few (around 4) lines to print out a warning for the cases without workaround (i.e. filled polylines/polygons). Best wishes, Alexander -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
