From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from lists.gentoo.org (pigeon.gentoo.org [208.92.234.80]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by finch.gentoo.org (Postfix) with ESMTPS id 658E11395E2 for ; Thu, 24 Nov 2016 23:49:56 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 00955E0B07; Thu, 24 Nov 2016 23:49:50 +0000 (UTC) Received: from avasout04.plus.net (avasout04.plus.net [212.159.14.19]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id 35A94E0ABC for ; Thu, 24 Nov 2016 23:49:48 +0000 (UTC) Received: from [192.168.6.125] ([46.208.76.211]) by avasout04 with smtp id Bzpm1u0014ZY9cm01zpn7p; Thu, 24 Nov 2016 23:49:47 +0000 X-CM-Score: 0.00 X-CNFS-Analysis: v=2.2 cv=T4LOdLCQ c=1 sm=1 tr=0 a=3fABx4uJ6eXoS02SKkQYwQ==:117 a=3fABx4uJ6eXoS02SKkQYwQ==:17 a=13zjGPudsaEWiJwPRgMA:9 a=WbPmnYzAfxEA:10 a=kgYyDsfIlEGjyk7OQ0sA:9 a=5yVUsU3EXdJeHNiG:21 a=RxVHDHFDpOX2pIp4:21 a=QEXdDO2ut3YA:10 a=zwtGHSquE5RIUNF44OoA:9 a=ONNS8QRKHyMA:10 Subject: Re: [gentoo-dev] Improving the stabilisation process - part 1 To: gentoo-dev@lists.gentoo.org References: <3decc9b3-f376-8c33-7565-39eae053a05c@gentoo.org> From: "M. J. Everitt" Openpgp: id=BA266E0525CFAB101523351B4C30334F93C22371 Message-ID: <58377C2F.9080100@iee.org> Date: Thu, 24 Nov 2016 23:47:59 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.0 Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-dev@lists.gentoo.org Reply-to: gentoo-dev@lists.gentoo.org MIME-Version: 1.0 In-Reply-To: <3decc9b3-f376-8c33-7565-39eae053a05c@gentoo.org> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="wVdBlpKcoQmHCcgTnMoED3IUtMsDlHaKF" X-Archives-Salt: 8fe1618b-69f1-4a0d-a733-cc6fdb5ae0a5 X-Archives-Hash: 1532e79b52124b8007c12835ac62599d This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --wVdBlpKcoQmHCcgTnMoED3IUtMsDlHaKF Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 24/11/16 19:41, 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 (wil= l > pass repoman) until someone actually tries it. > > 3. There's no easy way to identify the level of testing required for an= y > given request. > > To address this, I am proposing some changes to Bugzilla, some > automation, and some improved tools. > > > Bugzilla changes > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > 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 testi= ng > * 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 b= e > 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 bu= g. > > Example atom list from a bug with amd64, arm, and x86 in CC: > > =3Dapp-foo/bar-1.2.3 # will be stabilised on amd64, arm, and = x86 > =3Dapp-foo/baz-2.3.4 amd64 x86 # will be stabilised on only amd64 and x= 86 > > I'd also like to introduce a flag called "repoman-tested". This will be= > used identify stabilisation requests that have been automatically > repoman checked by a bot (described below). > > To prevent cluttering the Bugzilla interface, I suggest resurrecting th= e > "Stabilisation" component and having these new fields appear only for > bugs filed there and in "Security: Vulnerabilities" (so not to disrupt > the security team's workflow). > > > Automation > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > It's easy to forget to check that all the required dependencies are in > stable before filing a stabilisation test, but this wastes the actionin= g > developer's time. I have prepared a bot that repoman checks the list of= > atoms and flags the bug appropriately. This allows easy filtering out o= f > broken requests. > > > Improved tools > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > To support the above, I am also preparing some tools to streamline the > process further: > > * A script to, given a bug, produce an architecture-specific list of > atoms ready to feed into package.accept_keywords / emerge > > * An updated version of app-portage/tatt (allowing easy testing of USE > flag combinations, reverse dependencies, committing keyword changes etc= =2E) > > * Your idea here > > > Too long; didn't read > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > We add a new box to Bugzilla to hold atoms on stabilisation request bug= s > so it's easy to extract programmatically. > > We add a new box to Bugzilla to indicate if a stabilisation request > requires runtime testing or not to better focus effort. > > If your stabilisation request is invalid a bot will let you know and it= > will be easy to skip your request until you fix it. > > > This will also help pave the way for future enhancements such as > triggering automated build and QA tests so that the human only has to d= o > runtime testing. > > Thoughts? > +1 Doing a great job there, kensington :] Will grab a paint-brush for the 'shed, soon as my own have completed erection.... --wVdBlpKcoQmHCcgTnMoED3IUtMsDlHaKF Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iQIcBAEBCAAGBQJYN3yaAAoJEEwwM0+TwiNxXVUP/33/T2VWOUjWlqAoSnL6DAjK ee4edUo+tSHfcrZpQT6gCrPZo/CC/GE1GsBI0L5UUQgGx3gjQUUukgRUKycB+uvg IFighn8TKYbaOxIZbRo3k62OhvFDA0yU/32Z19eYQTfqiE183eABD0DFJozEr8xF AIvH15IDew/hHwpgXtI+UwkoxP/eblGVXTB78zl7vF3uHTnmbs8wtUA0Bu3HNH6d CEJucTkuUqJ5YrcAfxWRX51FbhrDGFy6niuzKN1W2USc3gY3H2Vly8vUlkaK20JB Iw/qfAx5G+sAFzLEIhgCet64NoHDGFJh4qUTwmeQx0yk8AwzKlQYTjTi6vRZEObj ErWIWXYZ0o7J3HJPqZpdyrQyStt8KOZS3Pw8eBafWQWweA3HZWk28Maexuol7dvW lJ9FON9lZjPeeWf9OYiRbYQLbIeqZ/x3yU2fzuCrbcNgIUx1MtEiRVCeZcuBqSkN 4u72VUm72matbA0K2Ps14VqsppjAMnxhlxz66F1RCh4tF0E9etVs7pRA0Vu/ERoi ScYTOQYvDOyAHCG4l7r1YNYeNrh3s5pQLXZgDl8ojHZi7gNRh4rbmnp0Su23dRvv CreXWhsSLgr+RyEVljP8t6spIoC1yySZxts3S/ejVBU6RJfuDJfmQo33BEf5ts48 AWAQeI30OYLkKap5kSts =KYGV -----END PGP SIGNATURE----- --wVdBlpKcoQmHCcgTnMoED3IUtMsDlHaKF--