Ideas for improving the release process

[Daniel van Vugt]

If a critical bug isn't blocking a release I guess it should be demoted 
to High.

We need some simple threshold that doesn't require the reader to 
understand the details of each bug. Just that "if importance >= critical 
then don't release". And there's no other level we can use for that 
other than critical (or 'high' later as the project matures).


On 17/02/16 04:09, Kevin Gunn wrote:
> inline comments
>
> On Mon, Feb 15, 2016 at 7:19 PM, Daniel van Vugt
> <daniel.van.vugt at canonical.com <mailto: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 <mailto:Mir-devel at lists.ubuntu.com>
>     Modify settings or unsubscribe at:
>     https://lists.ubuntu.com/mailman/listinfo/mir-devel
>
>