On 27/11/16 10:32, William Hubbs wrote: > On Fri, Nov 25, 2016 at 06:41:20AM +1100, Michael Palimaka wrote: >> As I am sure everyone is aware by now, stabilisation requests on many >> architectures take a long time to be actioned. There are many factors >> contributing to this, but today I'd like to address three specific >> problems that unnecessarily delay developers actioning those requests.: >> >> 1. There's no easy way to pick atoms out of a stabilisation bug. >> Currently, atoms can appear, in a varying formations, in multiple >> locations: in the bug title, spread across multiple comments, in an >> attachment, [...]. >> >> 2. There's no way to determine if a stabilisation request is valid (will >> pass repoman) until someone actually tries it. >> >> 3. There's no easy way to identify the level of testing required for any >> given request. >> >> To address this, I am proposing some changes to Bugzilla, some >> automation, and some improved tools. >> >> >> Bugzilla changes >> ================ >> >> I'd like to introduce two new fields: >> >> 1. "Runtime testing required" - a drop-down list with three values: >> * (unset) - the default. The stabilising developer will use >> their best judgement as to what testing is required >> * Yes - the maintainer is specifically requesting runtime testing >> * No - the maintainer is happy to stabilise with only a build >> test (for example, trivial revision bumps, libraries with good test >> coverage, or otherwise at the maintainer's discretion) >> >> 2. "Atoms to stabilise" - a textarea containing a list of fully >> qualified atoms. Each atom may optionally be followed by a >> whitespace-delimited list of architectures for which that atom should be >> stabilised. If an atom is not followed by any list of architectures, it >> is assumed it should be stabilised for all architectures CC'd on the bug. >> >> Example atom list from a bug with amd64, arm, and x86 in CC: >> >> =app-foo/bar-1.2.3 # will be stabilised on amd64, arm, and x86 >> =app-foo/baz-2.3.4 amd64 x86 # will be stabilised on only amd64 and x86 > > Listing the architectures seems redundant if they are also in the cc: > field. In your example above, why would you need arm in the cc: field > for app-foo/bas-2.3.4?
This is to handle the case where multiple packages are stabilised in a single bug and each package needs stabilising on a different set of architectures.
