-changes emails could be easier to read

This is even more noticeable with security uploads, where the ratio of useful information is even lower:

https://lists.ubuntu.com/archives/hardy-changes/2008-July/011890.html

If this distilled presentation of changes is to happen, I'd like for it also show who sponsored the upload. The only way I know of to get that information right now is to check the gpg signature on the .changes file, and I'd be sorry to see that go away.

On Mon, Aug 04, 2008 at 07:45:11AM -0000, Soren Hansen wrote:
> If this distilled presentation of changes is to happen, I'd like for it
> also show who sponsored the upload. The only way I know of to get that
> information right now is to check the gpg signature on the .changes
> file, and I'd be sorry to see that go away.

Good point, I agree.

--
 - mdz

Since this is quite an easy task and has high impact for the users we'll do this for the next roll out.

It's also good for Muharem to learn a bit about the upload system :)

Hello there!

I have made the requested changes (to the code) to make the upload notification emails more readable. An example notification email would look as follows:

==============================================

Subject: [ubuntu/hoary-security] bar 1.0-2 (Accepted)
Body:
-> changes file signed by: Foo Bar (<email address hidden>)
-> component=universe, section=devel

 bar (1.0-2) breezy; urgency=low

   * A second upload to ensure that binary overrides of _all work
   * Also closes Launchpad bug #6

-- Daniel Silverstone <email address hidden> Thu, 30 Mar 2006 01:36:14 +0100

==============================================

Please note:

  - the 'X-Launchpad-Component' header is set/sent as requested
  - only the most recent stanza from the 'Changes:' section is extracted and emailed

Please let me know what you think.

Thanks!

On Wed, Aug 06, 2008 at 05:08:30PM -0000, Muharem Hrnjadovic wrote:
> Hello there!
>
> I have made the requested changes (to the code) to make the upload
> notification emails more readable.

Thanks!

> An example notification email would look as follows:
>
> ==============================================
>
> Subject: [ubuntu/hoary-security] bar 1.0-2 (Accepted)
> Body:
> -> changes file signed by: Foo Bar (<email address hidden>)
> -> component=universe, section=devel
>
> bar (1.0-2) breezy; urgency=low
>
> * A second upload to ensure that binary overrides of _all work
> * Also closes Launchpad bug #6
>
> -- Daniel Silverstone <email address hidden> Thu, 30 Mar
> 2006 01:36:14 +0100
>
> ==============================================

Staying close to the changelog format is a good idea, since developers are
already accustomed to scanning this visually.

> Please note:
>
> - the 'X-Launchpad-Component' header is set/sent as requested

Can you show us an example X-Launchpad-Component header?

> - only the most recent stanza from the 'Changes:' section is extracted and emailed

To the extent possible, the email should reflect all of the changes
represented by the upload. As such, I think the full Changes: section
should be included.

(in fact, it would be even more accurate to extract the relevant stanzas
from debian/changelog and display that!)

--
 - mdz

Here's an example:

  >>> notification['X-Launchpad-Component']
  'component=universe, section=devel'

On Wed, Aug 06, 2008 at 05:36:30PM -0000, Muharem Hrnjadovic wrote:
> Here's an example:
>
> >>> notification['X-Launchpad-Component']
> 'component=universe, section=devel'

Should be fine for filtering, thanks.

--
 - mdz

On Wed, 2008-08-06 at 17:31 +0000, Matt Zimmerman wrote:
> On Wed, Aug 06, 2008 at 05:08:30PM -0000, Muharem Hrnjadovic wrote:
> > Hello there!
> >
> > I have made the requested changes (to the code) to make the upload
> > notification emails more readable.
>
> Thanks!
>
> > An example notification email would look as follows:
> >
> > ==============================================
> >
> > Subject: [ubuntu/hoary-security] bar 1.0-2 (Accepted)
> > Body:
> > -> changes file signed by: Foo Bar (<email address hidden>)
> > -> component=universe, section=devel
> >
> > bar (1.0-2) breezy; urgency=low
> >
> > * A second upload to ensure that binary overrides of _all work
> > * Also closes Launchpad bug #6
> >
> > -- Daniel Silverstone <email address hidden> Thu, 30 Mar
> > 2006 01:36:14 +0100
> >
> > ==============================================
>
> Staying close to the changelog format is a good idea, since developers are
> already accustomed to scanning this visually.
>
> > Please note:
> >
> > - the 'X-Launchpad-Component' header is set/sent as requested
>
> Can you show us an example X-Launchpad-Component header?
>
> > - only the most recent stanza from the 'Changes:' section is
> extracted and emailed
>
> To the extent possible, the email should reflect all of the changes
> represented by the upload. As such, I think the full Changes: section
> should be included.

Hello Matt,

including the complete 'Changes:' section in the notification email is
not a problem.

However, I may not have the complete information on each author
mentioned in the 'Changes:' section in which case I will not be able to
present the authors in the format used in Ubuntu changelogs.

> (in fact, it would be even more accurate to extract the relevant stanzas
> from debian/changelog and display that!)

I will look into this.

Best regards

--
Muharem Hrnjadovic <email address hidden>
Canonical Ltd.

Public key id : 607FAC52
Key fingerprint : 131E FA03 4525 0A6E 7029 29AD B717 2D69 607F AC52

On Wed, Aug 06, 2008 at 08:17:29PM -0000, Muharem Hrnjadovic wrote:
> On Wed, 2008-08-06 at 17:31 +0000, Matt Zimmerman wrote:
> > To the extent possible, the email should reflect all of the changes
> > represented by the upload. As such, I think the full Changes: section
> > should be included.
>
> Hello Matt,
>
> including the complete 'Changes:' section in the notification email is
> not a problem.
>
> However, I may not have the complete information on each author
> mentioned in the 'Changes:' section in which case I will not be able to
> present the authors in the format used in Ubuntu changelogs.

I understand; in fact, I filed a bug report about this issue over 7 years
ago!

http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=95579

It seems to have been closed, but the default behaviour is still to throw
away this information when creating .changes. Perhaps we should consider
changing this in Ubuntu...

--
 - mdz

A complete example:

Subject: [ubuntu/intrepid] hello 2.2-2 (Accepted)
X-Launchpad-Component: component=universe, section=devel

hello (2.2-2) intrepid; urgency=low

  * Removed all traces of checkroot. It's not really debian/rules job,
    and the binary target will fail anyway if not invoked as root,
    as there is a chown call.

 -- Santiago Vila <email address hidden> Wed, 11 Apr 2007 08:05:12 +0200

Changed-By: Some Ubuntu Dude <email address hidden>
Signed-By: Some sponsor <email address hidden>
Origin: Debian/unstable

Changed-By and Signed-By should be omitted if they're the same as Maintainer. Origin should only be provided for syncs. Here it is in terms of the .changes fields etc.:

Subject: [%(Distro)s/%(DistroSeries)s] %(Package)s %(Version)s (%(Status)s)
X-Launchpad-Component: ...

%(Source)s (%(Version)s) %(Distribution)s; urgency=%(Urgency)s

%(Decoded-Changes)s

 -- %(Maintainer)s %(Date)s

Changed-by: %(Changed-By)s
Signed-By: %(Email-Address-Matching-Key)s
Origin: %(Origin)s

Muharem, in the above example you should be able to retrieve everything from the line:

hello (2.2-2) intrepid; urgency=low

to the line:

 -- Santiago Vila <email address hidden> Wed, 11 Apr 2007 08:05:12 +0200

inclusive, straight out of SPR.changelog_entry.

On Thu, 2008-08-07 at 09:53 +0000, Matt Zimmerman wrote:
> A complete example:
>
> Subject: [ubuntu/intrepid] hello 2.2-2 (Accepted)
> X-Launchpad-Component: component=universe, section=devel
>
> hello (2.2-2) intrepid; urgency=low
>
> * Removed all traces of checkroot. It's not really debian/rules job,
> and the binary target will fail anyway if not invoked as root,
> as there is a chown call.
>
> -- Santiago Vila <email address hidden> Wed, 11 Apr 2007 08:05:12 +0200
>
> Changed-By: Some Ubuntu Dude <email address hidden>
> Signed-By: Some sponsor <email address hidden>
> Origin: Debian/unstable
>
> Changed-By and Signed-By should be omitted if they're the same as
> Maintainer. Origin should only be provided for syncs. Here it is in
> terms of the .changes fields etc.:
>
> Subject: [%(Distro)s/%(DistroSeries)s] %(Package)s %(Version)s (%(Status)s)
> X-Launchpad-Component: ...
>
> %(Source)s (%(Version)s) %(Distribution)s; urgency=%(Urgency)s
>
> %(Decoded-Changes)s
>
> -- %(Maintainer)s %(Date)s
>
> Changed-by: %(Changed-By)s
> Signed-By: %(Email-Address-Matching-Key)s
> Origin: %(Origin)s

Hello Matt,

thanks again for the complete example provided above. Celso pointed out
that the 'Origin:' field is not a documented one (he was referring to
http://www.debian.org/doc/debian-policy/ch-controlfields.html).

Could you please explain why you are requesting that field to be
included?

Best regards

--
Muharem Hrnjadovic <email address hidden>
Canonical Ltd.

Public key id : 607FAC52
Key fingerprint : 131E FA03 4525 0A6E 7029 29AD B717 2D69 607F AC52

On Thu, Aug 14, 2008 at 06:48:36AM -0000, Muharem Hrnjadovic wrote:
> thanks again for the complete example provided above. Celso pointed out
> that the 'Origin:' field is not a documented one (he was referring to
> http://www.debian.org/doc/debian-policy/ch-controlfields.html).
>
> Could you please explain why you are requesting that field to be
> included?

In Ubuntu, the Origin field records whether the package was copied in from
an external repository (most commonly Debian) or originated in Ubuntu. This
is important information for the notification emails.

It's been discussed in Debian since before Ubuntu existed, and draft
proposals exist.

BTW, could you be sure to solicit comments from ubuntu-devel@ before rolling
the change out? There may be scripts processing these emails, so a change
of format needs to be coordinated.

--
 - mdz

Considering that the vast majority of packages in Ubuntu are team maintained, and so neither Changed-By: or Signed-By: are particularly likely to match Maintainer:, would it not be more interesting to hide Signed-By: in those cases where it matches Changed-By:, rather than in those cases where it matches Maintainer:?

Also, if it is decided to match Maintainer:, it may be preferable to also check the contents of Uploaders: and not show in that case as well: this would match the Debian behaviour of not considering an upload to be an NMU in cases where the uploader matches any of the addresses in Uploaders.

I think the cases we need to consider are: 1. "X uploaded their own changes to Ubuntu", 2. "X uploaded Y's changes to Ubuntu", and 3. "X synced in Y's changes from Debian"

1. Changed-By and Signed-By are the same. The changes should be attributed to that person on the last line of the changes (where I wrote %(Maintainer)s above)

2. Changed-By and Signed-By are different. The changes should be attributed to Changed-By as above, and a Signed-By field should be included to show who sponsored the changes

3. The change is a sync from another repository. The changes should be attributed to the original uploader if we have that (I don't think we do yet), otherwise it should be attributed to the entity from which it was synced (e.g. "Copied from Debian") with an appropriate Ubuntu role address (<email address hidden>?)

I forgot to mention, in 3. the requestor of the sync should go in a Changed-By field

In case 3 above, when the requestor is not normally authorised to upload to the component into which the sync is imported, would it also be interesting to capture the person who authorised the sync (essentially, the sync sponsor)? Currently this is only captured in the bug report for the sync, but not exported anywhere.

On Thu, Aug 14, 2008 at 12:57:37PM -0000, Emmet Hikory wrote:
> In case 3 above, when the requestor is not normally authorised to upload
> to the component into which the sync is imported, would it also be
> interesting to capture the person who authorised the sync (essentially,
> the sync sponsor)? Currently this is only captured in the bug report
> for the sync, but not exported anywhere.

This might be an interesting future enhancement, though I think it's OK to
start with reformatting the data we already present in a more useful way and
tackle this separately.

--
 - mdz

Will the new-format mail still have an X-Katie header?
When will this change be rolled out?

What will be the From: address?

The format in Matt's complete example doesn't parse as rfc2822 message. Can we please keep those messages parseable? It's a matter of adding the 'Changes:' header back and ensuring the changes are properly indented and contain no blank lines, just as the current format.

On Sun, Aug 17, 2008 at 10:37:18AM -0000, Dennis Kaarsemaker wrote:
> The format in Matt's complete example doesn't parse as rfc2822 message.
> Can we please keep those messages parseable? It's a matter of adding the
> 'Changes:' header back and ensuring the changes are properly indented
> and contain no blank lines, just as the current format.

The example is in Debian changelog format, for which parsers already exist
in several languages.

--
 - mdz

The debian changelog format does not specify any additional fields besides a structured list of changes. The debian .changes format does and is also an rfc2822-like format. The example is a mix of both, starting with a debian changelog and appending some extra rfc2822-like fields.

On Sun, Aug 17, 2008 at 02:32:48PM -0000, Dennis Kaarsemaker wrote:
> The debian changelog format does not specify any additional fields
> besides a structured list of changes. The debian .changes format does
> and is also an rfc2822-like format. The example is a mix of both,
> starting with a debian changelog and appending some extra rfc2822-like
> fields.

The purpose of this suggestion was to replace an email format which is hard
for humans to read (.changes files) with one which is easy for humans to
read (changelog entries), since emails are primarily for humans to read.

There should be more convenient ways of accessing this data programmatically
(perhaps launchpadlib?), but if not, perhaps it would be easiest if
Launchpad simply attached a copy of the .changes file to the message.

Then, scripts could continue to parse that, while humans could ignore it and
read the content.

--
 - mdz

On Sunday 17 August 2008 11:11:17 Dennis Kaarsemaker wrote:
> Will the new-format mail still have an X-Katie header?

Yes.

> When will this change be rolled out?

The target date is Wednesday 20th.

Hi,

personally I'm quite interested of what files an upload consists of (i.e. if there's an orig.tar.gz attached to it or not).

Others than that, I think adding a parser to library which everyone interested in fiddling with these new "changes" files can use sounds like a very good idea.

Cheers,
   Stefan.

On Sun, 2008-08-17 at 15:12 +0000, Matt Zimmerman wrote:
> On Sun, Aug 17, 2008 at 02:32:48PM -0000, Dennis Kaarsemaker wrote:
> > The debian changelog format does not specify any additional fields
> > besides a structured list of changes. The debian .changes format does
> > and is also an rfc2822-like format. The example is a mix of both,
> > starting with a debian changelog and appending some extra rfc2822-like
> > fields.
>
> The purpose of this suggestion was to replace an email format which is hard
> for humans to read (.changes files) with one which is easy for humans to
> read (changelog entries), since emails are primarily for humans to read.
>
> There should be more convenient ways of accessing this data programmatically
> (perhaps launchpadlib?), but if not, perhaps it would be easiest if
> Launchpad simply attached a copy of the .changes file to the message.
This is a very good idea! I will revise the notification email sending
logic accordingly.

> Then, scripts could continue to parse that, while humans could ignore it and
> read the content.
This is the best of both worlds.

Best regards

--
Muharem Hrnjadovic <email address hidden>
Canonical Ltd.

Public key id : 607FAC52
Key fingerprint : 131E FA03 4525 0A6E 7029 29AD B717 2D69 607F AC52

> There should be more convenient ways of accessing this data
> programmatically
> (perhaps launchpadlib?), but if not, perhaps it would be easiest if
> Launchpad simply attached a copy of the .changes file to the message.

That would certainly make my life easier :)

I just filed a new spec:

https://blueprints.edge.launchpad.net/soyuz/+spec/upload-rss-feed

Making this data available in the Launchpad API would also be beneficial
for folks who need to programmatically access the data. Soyuz will be
gaining API access in the forthcoming months.

Deferred to 2.1.9 until the final format is nailed down.

So long as we're changing the format, could we add a link to the source package release? In combination with bug 246534 (now fixed), this would make browsing diffs very convenient!

On Sat, 2008-08-23 at 13:52 +0000, Matt Zimmerman wrote:
> So long as we're changing the format, could we add a link to the source
> package release? In combination with bug 246534 (now fixed), this would
> make browsing diffs very convenient!

Hello Matt,

thanks for suggesting this. I have revised the code to add a source
package release URL to the notification email where appropriate.

BTW, where do we stand re. the roll-out of the notification email format
change? What are the prerequisites missing (if any)?

Best regards

--
Muharem Hrnjadovic <email address hidden>
Canonical Ltd.

Public key id : 607FAC52
Key fingerprint : 131E FA03 4525 0A6E 7029 29AD B717 2D69 607F AC52

Since I was asked for my sign-off, I'm by and large in favour of this change.

The one thing I remain unsure of is how we're handling uploads that include changelog entries from multiple package versions in their .changes file. Matt suggested extracting the information from debian/changelog in the uploaded source package, which I think is a good idea, but this is definitely worth a test case.

It is important to include at least some data for all the changelog entries in the .changes file in the announcement mails (contrast this with /ubuntu/+source/SP, which doesn't reliably do this). It is desirable to preserve the trailer line from each changelog entry that names the person responsible; failing that, we must not synthesise trailer lines because that could reassign credit to the wrong person, and it would be better just to leave out trailer lines if we can't create them correctly.

I've attached a .changes file that would make a decent test case. It corresponds to https://launchpad.net/ubuntu/+source/fbreader/0.8.17-11ubuntu1; note that the change information displayed on https://launchpad.net/ubuntu/+source/fbreader is truncated, which is what we don't want to happen to announcement mails. I'd like to see what the announcement mail for this upload would have looked like under the new system.

On Monday 01 September 2008 13:43:49 Colin Watson wrote:
> note
> that the change information displayed on
> https://launchpad.net/ubuntu/+source/fbreader is truncated, which is
> what we don't want to happen to announcement mails. I'd like to see what
> the announcement mail for this upload would have looked like under the
> new system.

Colin, as you saw last week, preserving multiple revisions of changelogs is on
the priority list for Soyuz in the work for 3.0 but is not a trivial change
unfortunately.

In the meantime, we're attaching the .changes file as per the previous
comments on this bug. This should hopefully let you see the info you need!

Cheers.

On Mon, Sep 01, 2008 at 12:43:49PM -0000, Colin Watson wrote:
> Since I was asked for my sign-off, I'm by and large in favour of this
> change.

OK, with your approval, and the attachment of the original .changes file to
support scripts which want this format, I think that all of the previous
concerns raised have been addressed.

> The one thing I remain unsure of is how we're handling uploads that
> include changelog entries from multiple package versions in their
> .changes file. Matt suggested extracting the information from
> debian/changelog in the uploaded source package, which I think is a good
> idea, but this is definitely worth a test case.

To clarify, I think it would be great to extract the complete changes, but
this doesn't need to block the initial deployment. It would be sufficient
to include the information currently available in .changes (since that's no
worse than what we have today).

--
 - mdz

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.

Colin - I think I misunderstood you slightly, apologies.

The full changelog from the .changes really ought to be there in the email
already so Muharem is looking into why this is a problem. Hopefully it's an
easy one to fix, because as you say we already have the required content.

He'll post an example email back here in due course.

The attachment contains an email that corresponds to the fbreader 0.8.17-11ubuntu1 changes file (sans the Signed-By: line if one was in order)

On Mon, Sep 01, 2008 at 04:16:37PM -0000, Muharem Hrnjadovic wrote:
> The attachment contains an email that corresponds to the fbreader
> 0.8.17-11ubuntu1 changes file (sans the Signed-By: line if one was in
> order)
>
>
> ** Attachment added: "upload notification email example for package fbreader 0.8.17-11ubuntu1"
> http://launchpadlibrarian.net/17210286/0.8.17-11ubuntu1-example.txt

That looks pretty good to me.

A blank line between the changelog separator ("-- Ubuntu MOTU...") and the
Changed-By field would improve readability.

"Ubuntu Linux" would presumably be the name of the distro instead (which is
just "Ubuntu" in Launchpad and elsewhere).

--
 - mdz

On Monday 01 September 2008 17:30:02 Matt Zimmerman wrote:
> "Ubuntu Linux" would presumably be the name of the distro instead (which is
> just "Ubuntu" in Launchpad and elsewhere).

That's just our crap sample data! In production it will be fine.

Thanks, this is largely fine, assuming that the .changes will be attached in the real thing. As Matt said, a blank line would help. Also:

  * We are used to reading changelog trailer lines as " -- name <e-mail> date" (note leading space, and two spaces between e-mail and date; it would be helpful to match that.
  * Using the Maintainer for the changelog trailer line is weird, because it doesn't correspond to what would be in the real changelog. I suggest using Changed-By for this instead (Bhavani Shankar in this case), and including a Maintainer: line for ubuntu-motu. Matt summarised the possibilities in comments 16 and 17 to this bug, which could be turned into test cases.
  * It would be better for the synthesised changelog trailer line to be just below the first changelog block, rather than right at the end. As it is, it looks as if ubuntu-motu (or Bhavani) was responsible for version 0.8.14-2, which isn't the case; that trailer line belongs with version 0.8.17-11ubuntu1.

On Mon, Sep 01, 2008 at 04:42:44PM -0000, Colin Watson wrote:
> Thanks, this is largely fine, assuming that the .changes will be
> attached in the real thing. As Matt said, a blank line would help. Also:
>
> * We are used to reading changelog trailer lines as " -- name <e-mail> date" (note leading space, and two spaces between e-mail and date; it would be helpful to match that.

Agreed.

> * Using the Maintainer for the changelog trailer line is weird, because it doesn't correspond to what would be in the real changelog. I suggest using Changed-By for this instead (Bhavani Shankar in this case), and including a Maintainer: line for ubuntu-motu. Matt summarised the possibilities in comments 16 and 17 to this bug, which could be turned into test cases.

Agreed.

> * It would be better for the synthesised changelog trailer line to be just below the first changelog block, rather than right at the end. As it is, it looks as if ubuntu-motu (or Bhavani) was responsible for version 0.8.14-2, which isn't the case; that trailer line belongs with version 0.8.17-11ubuntu1.

This is going to be awkward no matter what, since the relevant data is
currently lost and the format doesn't degrade gracefully. I suppose you're
right, though. The additional changelog stanzas without maintainer fields
will look weird, but not much weirder than the current example.

--
 - mdz

just to understand it right: the real example file would contain a signed-by line (if appropriate)?

Stefan,

yes, that's right, the real notification email will contain a signed-by line where appropriate.

Since it would take quite a bit of effort to put the synthesized trailer line after the pertinent changelog section, Colin was kind enough to make the following suggestion:

"if you can't put the synthesised trailer line in the right place, it would be better to format it as "Key: value" lines rather than pretending it's a changelog trailer"

.. and (barring any objections) that's the format that will be implemented.

Would it be possible to synthesize a sample of that format for discussion and review?

bar (1.0-10) breezy; urgency=3Dlow

  * Changes file that contains UTF-8

  * Non-ascii text: =C4=8Ciha=C5=99

Date: Thu, 30 Mar 2006 01:36:14 +0100
Changed-By: Čihař <email address hidden>
Maintainer: Non-ascii maintainer <email address hidden>
Signed-By: Foo Bar <email address hidden>
Source package release: http://launchpad.dev/ubuntu/hoary/+source/bar/1.0-10

==

Announcing to <email address hidden>

Thank you for your contribution to Ubuntu Linux.

--

You are receiving this email because you are the uploader, maintainer or
signer of the above package.

On Tue, Sep 02, 2008 at 03:14:07PM -0000, Muharem Hrnjadovic wrote:
> Since it would take quite a bit of effort to put the synthesized trailer
> line after the pertinent changelog section, Colin was kind enough to
> make the following suggestion:
>
> "if you can't put the synthesised trailer line in the right place, it
> would be better to format it as "Key: value" lines rather than
> pretending it's a changelog trailer"
>
> .. and (barring any objections) that's the format that will be
> implemented.

Sounds fine.

--
 - mdz

Muharem: That looks fine to me, assuming that the quoted-printable encoding there will be properly tagged in the mail headers.

(The three blank lines in http://launchpadlibrarian.net/17243656/example-email.txt seem unnecessary; one blank line would be fine there.)

Colin, thanks for the feedback. The quoted-printable encoding is properly indicated by the email headers. I will take care of the superfluous blank lines.

RF 7034

Surely this should be Fix Committed, not Fix Released? It hasn't been deployed yet.

If you can give us a date when this will be deployed (the next LP release?) then we'd appreciate warning of that so that we can warn people who are relying on the current mail format.

Oops, sorry, you are right, it is still "fix committed" at this point.

FWIW I actually did send out an email to <email address hidden> (on Wed, 17 Sep 2008 12:31:30 +0200). It probably got stuck in the moderator's inbox.

{{{
Hello,

I just wanted to remind you that the email format change for upload
notifications (please see
https://bugs.edge.launchpad.net/soyuz/+bug/250820 for details) is one of
the 2.1.9 Soyuz features that will be rolled out tonight if all goes
well.

The body of the email will contain the changes file content in a format
that is easier to read for humans.

Please note: the original changes file will be enclosed in the email as
an attachment.
}}}

The branch implementing this feature got delayed a bit but the re-rollout (occurring tonight?) will include it.

Eek, no time to lose then. I've moderated your mail.