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