Comment 38 for bug 250820

Julian: I don't understand this problem at all. I understand that it may be difficult to preserve the .changes content in the database for future use in the web UI. However, you manifestly have the .changes content in your hand when you're preparing to send the mail - you're proposing to attach it, after all! Thus it makes no sense to me to say that "preserving" this data is a blocker for getting the e-mail content right, because you have that data right there in front of you. All you need to do is munge it into a different format for the e-mail.

Also, I hope the information I gave clarifies my comment on the conference line that this problem is not limited to native source syncing.

I agree that attaching the .changes is just about minimally sufficient to address the issue of multiple versions in a single .changes. It is very unfortunate, though, that it would mean that the easy-to-read part of the mail will be insufficient to get a summary of all the changes since the last version in Ubuntu, and thus that many people will end up simply reading the .changes anyway. I wonder if this would actually help us much, and I would much prefer to see my "important" section from https://bugs.launchpad.net/soyuz/+bug/250820/comments/34 addressed before this is deployed. As described above, I don't think it should be hard. Simply parsing out the Changes field from the .changes file, removing the first column of spaces, and then dropping lines consisting only of a dot would be quite sufficient for an initial implementation, even if figuring out a changelog trailer line would be better.

All that aside, I would still like to see what an announcement mail corresponding to my test case would look like. I don't mind if it's constructed by hand based on what the code is supposed to do, if it's too hard to run it through automatically.