Ideas for improving the release process

Daniel van Vugt daniel.van.vugt at
Wed Feb 17 01:08:12 UTC 2016

If a critical bug isn't blocking a release I guess it should be demoted 
to High.

We need some simple threshold that doesn't require the reader to 
understand the details of each bug. Just that "if importance >= critical 
then don't release". And there's no other level we can use for that 
other than critical (or 'high' later as the project matures).

On 17/02/16 04:09, Kevin Gunn wrote:
> inline comments
> On Mon, Feb 15, 2016 at 7:19 PM, Daniel van Vugt
> <daniel.van.vugt at <mailto:daniel.van.vugt at>>
> wrote:
>     Someone should add(!) to the list of manual steps:
>     Check for open critical bugs. If a bug is critical it should block
>     any release:
> I disagree with this, but I'll guess that means we might disagree on how
> Critical is used.
> Critical means Fix now or as soon as possible.
> which to me means "this is one of the most important thing" could
> have 2 criticals, you fix one, you'd certainly want to release that even
> if you were stumped on the 2nd.
> Also, you might be assuming the bug only exists on devel.
> That's not to say you'd never have a bug that would "block"'s more
> case by case.
> So I would agree with wording like
> "Check for open critical bugs. Determine if a bug is a blocker (e.g.
> it's _only_ on devel and would be catastrophic to release, or is already
> in release and needs fixing ASAP):"
>     On 13/02/16 01:08, Cemil Azizoglu wrote:
>         Hi,
>         We talked about the release process and how it could be
>         improved. Here
>         are some ideas. Please add if you have others.
>         (Jenkaas could be leveraged for some)
>           1. Minimizing the manual steps (like creation of the next
>         target branch
>              on lp, etc) using scripts/launchpad API.
>           2. 'make release' target that 'll check for ABI breakage,
>         perhaps even
>              prepopulate the changelog with some static info, etc.
>           3. Downstreams' build/sanity testing could be done as part of MP
>              autolanding to identify breaks.
> where exactly - autolanding on devel?
>           4. Downstreams' release testing. How useful are AP tests for U8
>              and Browser? General opinion is 'not very'. Should we look into
>              doing away with them? Or at least identify the subset of
>         them that
>              is relevant to Mir, and run them during every release as
>         part of
>              autolanding as a 'nonblocking' test.
> I am not opposed to pruning down the list because it is a time killer.
> however, one reason we are running these AP tests is due to the fact
> we've broken them before with Mir releases. I would suggest if we want
> to prune the tests, to engage with unity8 & web browser team to work up
> a list of the individual AP tests we should run.
>         As always I'll be creating a trello card for this.
>         Thanks
>         Cemil Azizoglu
>         Mir Display Server - Team Lead
>         Canonical USA
>     --
>     Mir-devel mailing list
>     Mir-devel at <mailto:Mir-devel at>
>     Modify settings or unsubscribe at:

More information about the Mir-devel mailing list