We don't need a new definition. Just that if there are open critical
bugs, it would be a good idea to familiarise ourselves with them before
proceeding with the release. Because someone has marked it as critical
for some reason.
Tangentially I'm reminded of the wider Ubuntu problem with "Fix
Released" not being what new users would expect. We mark bugs as "Fix
Released" in Ubuntu even if the Ubuntu series the fix is "released" in
is 6 months away from being actually released. But that's a limitation
of Launchpad right now.
On 18/02/16 09:47, Kevin Gunn wrote:
the interesting thing is when you create a new vernacular within a team
- the rest of the world thinks you're saying Schedule to fix soon.
instead of
Fix now or as soon as possible.
and the rest of the world has no way to tell you Fix now or as soon as
possible.
On Wed, Feb 17, 2016 at 7:23 PM, Daniel van Vugt
<daniel.van.v...@canonical.com <mailto:daniel.van.v...@canonical.com>>
wrote:
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.w...@canonical.com <mailto:stephen.w...@canonical.com>
<mailto:stephen.w...@canonical.com
<mailto:stephen.w...@canonical.com>>> 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.w...@canonical.com
<mailto:stephen.w...@canonical.com>
<mailto:stephen.w...@canonical.com
<mailto:stephen.w...@canonical.com>>>
--
Mir-devel mailing list
Mir-devel@lists.ubuntu.com <mailto:Mir-devel@lists.ubuntu.com>
<mailto:Mir-devel@lists.ubuntu.com
<mailto:Mir-devel@lists.ubuntu.com>>
Modify settings or unsubscribe at:
https://lists.ubuntu.com/mailman/listinfo/mir-devel
--
Mir-devel mailing list
Mir-devel@lists.ubuntu.com
Modify settings or unsubscribe at:
https://lists.ubuntu.com/mailman/listinfo/mir-devel
