Ideas for improving the release process

Daniel van Vugt daniel.van.vugt at canonical.com
Tue Feb 16 01:19:39 UTC 2016


Someone should add(!) to the list of manual steps:

Check for open critical bugs. If a bug is critical it should block any 
release:
https://bugs.launchpad.net/mir/+bugs?search=Search&field.importance=Critical


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.
>  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.
>
> As always I'll be creating a trello card for this.
>
> Thanks
> Cemil Azizoglu
> Mir Display Server - Team Lead
> Canonical USA
>
>



More information about the Mir-devel mailing list