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.v...@canonical.com <mailto: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=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@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
