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=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 > 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
