Ideas for improving the release process

Alan Griffiths alan.griffiths at canonical.com
Fri Feb 12 17:18:31 UTC 2016


On 12/02/16 17: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
>
>

Essentially, we have to cater for two types of release:

1. release changes from (development) trunk to a brand new series; and,
2. cherry-picking from (development) trunk to an existing series (or,
very occasionally fixing on the series directly)

In theory, there should be a third one: releasing changes from
development to the current series - but our server ABI isn't
sufficiently stable to do that.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ubuntu.com/archives/mir-devel/attachments/20160212/f2450bf0/attachment.html>


More information about the Mir-devel mailing list