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
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, D
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 ope
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 c
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".
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
>
>
>>> 3. Downstreams' build/sanity testing could be done as part of MP
>>> autolanding to identify breaks.
>>>
>>
> where exactly - autolanding on devel?
>
Yes
>
>
>> 4. Downstreams' release testing. How useful are AP tests for U8
>>> and Browser? General opinion is 'not very'. S
inline comments
On Mon, Feb 15, 2016 at 7:19 PM, Daniel van Vugt <
daniel.van.v...@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=Searc
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
On 13/02/16 01:08, Cemil Azizoglu wrote:
Hi,
We talked about the release process an
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
10 matches
Mail list logo
