Ideas for improving the release process

Daniel van Vugt daniel.van.vugt at
Thu Feb 18 01:23:15 UTC 2016

It's less of an issue if we also remember to review release branches 
before top approving them. In that case, hopefully code reviewers will 
also check for open critical bugs and mention them.

But yeah I feel we're not utilizing the importance field if we're 
allowing critical bugs to remain open without anyone even checking on 
them during the release process.

BTW, I demoted the remaining ones to High yesterday so all criticals are 
now resolved :)

On 17/02/16 21:48, Kevin Gunn wrote:
> So are you both tied to the idea of using Critical/High for this?
> as the lp definition/intimations for Critical/High don't really match
> the "blocker" use, would you be ok with using a tag "blocker" instead?
> can't see how a tag is any more costly and gets the job done all the same.
> ultimately the call is Stephen's.
> If you choose the Critical/High....just needs to be a) outlined
> somewhere & b) added to the release instructions like duflu originally
> asked.
> br,kg
> On Tue, Feb 16, 2016 at 8:59 PM, Stephen M. Webb
> <stephen.webb at <mailto:stephen.webb at>> wrote:
>     On 16-02-16 08:08 PM, Daniel van Vugt wrote:
>     > 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).
>     I have to agree with this.  If the bug is not critical enough to
>     block a release, it shouldn't be classed as critical.
>     --
>     Stephen M. Webb  <stephen.webb at
>     <mailto:stephen.webb at>>
>     --
>     Mir-devel mailing list
>     Mir-devel at <mailto:Mir-devel at>
>     Modify settings or unsubscribe at:

More information about the Mir-devel mailing list