<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"> <html> <head> <meta content="text/html;charset=UTF-8" http-equiv="Content-Type"> </head> <body bgcolor="#ffffcc" text="#000000"> Martin Meredith wrote: <blockquote cite="mid441814E1.8040308@ubuntu.com" type="cite"> <pre wrap="">When you're uploading - you're only uploading to one distribution - which is shown in the changelog entry. </pre> </blockquote> Yes, but that same package might then be uploaded to a derivative. This is the case when a package moves from, say, Debian to Ubuntu to GuadaLinux. We need to infer the "task" that is being updated from the place where we see the upload happening. <blockquote cite="mid441814E1.8040308@ubuntu.com" type="cite"> <pre wrap="">For Example, lets Say Bug 2001 Appears in Debian, Ubuntu And Foo (Upstream) Now, uploading to dapper, you're closing bug malone 2001 - surely soyuz will only Close the bug in Ubuntu - as well - you're not making an upload to Debian are you, </pre> </blockquote> Exactly! But that package might then be uploaded somewhere else. We need to watch the upload, not only look at the changelog. <blockquote cite="mid441814E1.8040308@ubuntu.com" type="cite"> <pre wrap="">So Closing only the bug in the distribution you're uploading to makes sense. You should change the other things when they're either uploaded to debian, or a new upstream tarball is released. In Reference to Mark's post about instructions to Launchpad in the Changelog.... I personally don't think this is a good idea... as surely it isn't something that should be in a changelog? </pre> </blockquote> Launchpad bug numbers and spec names are sort of universal. That means that you can talk to launchpad from anywhere, about anywhere else. By "instructions to launchpad" I mean that it is interesting to design the format that it includes information about not just bugs, but potentially also specs, or support tickets... Mark </body> </html>