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?
William
signature.asc
Description: Digital signature
