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