[08:12] <alan_g> duflu: do we mention bugs that were not evident in 0.12 or ones that correspond to listed features?
[08:13] <duflu> alan_g: Usually everything. But I get what you mean
[08:14] <duflu> alan_g: Those bugs that weren't evident have "Invalid" Ubuntu tasks. But yeah document everything in the changelog
[08:15] <alan_g> OK, thanks
[09:05] <alan_g> duflu: pushed
[09:05] <duflu> alan_g: Kay
[09:06] <alan_g> duflu: AFAIK we're ready to branch as soon as lp:~alan-griffiths/mir/update-changelog lands. Can you think of anything we should wait on?
[09:08] <duflu> alan_g: No, never need to wait really. Just branch ASAP and backport anything that's missing. It's better to have a quiet branch and massage that
[09:09] <alan_g> I know we can sync afterwards, but it is nice to tag and branch as one event. It isn't as though trunk should be in a broken state
[09:28] <duflu> alan_g: The v0.13.0 tag lives in the 0.13 branch, so not a major issue
[09:50] <alan_g> FFS today switching VTs from and back to mir servers seems to be broken. Even with the binaries that worked yesterday.
[10:20] <duflu> alan_g: Try switching to an intermediate VT before Mir (https://bugs.launchpad.net/mir/+bug/1409133)
[10:22]  * duflu -> weekend
[10:50]  * alan_g thinks duflu didn't read what I said. It is VT switching that is broken. (But only on my desktop)
[11:20] <greyback_> ERROR: unrecognised exception. (This is weird!)
[11:20] <greyback_> FATAL: exception not rethrown
[11:20] <greyback_> nicely put ;)
[15:32] <alan_g> camako: for a USC release do I need to create a changelog entry? It looks like the existing ones were created by a bot.
[15:36] <AlbertA> alan_g: no only if the version is changed (i.e. 0.0.7)
[15:41] <alan_g> Cool thanks
[15:42] <camako> alan_g, yep the bot will put what's in the MP's commit msg into the changelog
[15:42] <camako> automatically
[15:42]  * alan_g thinks duflu would argue with it