Ideas for improving the release process

Kevin Gunn kevin.gunn at canonical.com
Tue Feb 16 20:09:15 UTC 2016


inline comments

On Mon, Feb 15, 2016 at 7:19 PM, Daniel van Vugt <
daniel.van.vugt at canonical.com> wrote:

> 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
>
>
I disagree with this, but I'll guess that means we might disagree on how
Critical is used.
Critical means Fix now or as soon as possible.
which to me means "this is one of the most important thing"...you could
have 2 criticals, you fix one, you'd certainly want to release that even if
you were stumped on the 2nd.
Also, you might be assuming the bug only exists on devel.

That's not to say you'd never have a bug that would "block"...it's more
case by case.
So I would agree with wording like
"Check for open critical bugs. Determine if a bug is a blocker (e.g. it's
_only_ on devel and would be catastrophic to release, or is already in
release and needs fixing ASAP):"


> 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.
>>
>
where exactly - autolanding on devel?


>  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.
>>
>>
I am not opposed to pruning down the list because it is a time killer.
however, one reason we are running these AP tests is due to the fact we've
broken them before with Mir releases. I would suggest if we want to prune
the tests, to engage with unity8 & web browser team to work up a list of
the individual AP tests we should run.


> As always I'll be creating a trello card for this.
>>
>> Thanks
>> Cemil Azizoglu
>> Mir Display Server - Team Lead
>> Canonical USA
>>
>>
>>
> --
> Mir-devel mailing list
> Mir-devel at lists.ubuntu.com
> Modify settings or unsubscribe at:
> https://lists.ubuntu.com/mailman/listinfo/mir-devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ubuntu.com/archives/mir-devel/attachments/20160216/fbc7b799/attachment.html>


More information about the Mir-devel mailing list