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.
-- Mir-devel mailing list Mir-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/mir-devel
