Subject: Changelog quality

From: Cemil Azizoglu <[email-masked]>
Date: Fri, 6 Jun 2014 09:45:52 -0500

There is a discussion going on on ubuntu-phone about this. Having gone
through the release process where I've had to make sure the changelog is
accurate, I think it's a good time to discuss this within the team.

Currently, we seem to complete the changelog when we release, which makes
it difficult to come up with an accurate picture of what went into the
release (unless you're Daniel, blessed with the attention-to-detail gene).
I propose some ideas here, some of which are requested by the CI team:

1- Committer updates the changelog (as part of the same commit)
2- If it's a bug fix, add the LP#.
3- If it's a new feature, explain briefly what it is.
4- If it's an ABI break, point it out, along with a broad description of
what was added/deleted/changed.
5- If there is a change in dependencies, point it out.

Feel free to add/modify this list and we can discuss it in more detail on a
standup next week.

-- 
Cemil Azizoglu
Mir Display Server - Team Lead
Canonical USA

---

From: Alan Griffiths <[email-masked]>
Date: Fri, 06 Jun 2014 15:52:00 +0100

On 06/06/14 15:45, Cemil Azizoglu wrote:
> through the release process where I've had to make sure the changelog
> is accurate, I think it's a good time to discuss this within the team.
>
> Currently, we seem to complete the changelog when we release, which
> makes it difficult to come up with an accurate picture of what went
> into the release (unless you're Daniel, blessed with the
> attention-to-detail gene). I propose some ideas here, some of which
> are requested by the CI team:
>

Yeah, get Tarmac to do it! ;)

If you really mean "proposer" then the problem is that all concurrent
MPs will be updating the file at the same point and that will quickly
lead to bzr merge conflicts.