Ideas for improving the release process
Daniel van Vugt
daniel.van.vugt at canonical.com
Wed Feb 17 01:08:12 UTC 2016
If a critical bug isn't blocking a release I guess it should be demoted
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.vugt at canonical.com <mailto:daniel.van.vugt at canonical.com>>
> Someone should add(!) to the list of manual steps:
> Check for open critical bugs. If a bug is critical it should block
> any release:
> 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:
> 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.
> Cemil Azizoglu
> Mir Display Server - Team Lead
> Canonical USA
> Mir-devel mailing list
> Mir-devel at lists.ubuntu.com <mailto:Mir-devel at lists.ubuntu.com>
> Modify settings or unsubscribe at:
More information about the Mir-devel