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 8026713832E for ; Tue, 9 Aug 2016 10:06:34 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 4D49921C06D; Tue, 9 Aug 2016 10:06:32 +0000 (UTC) Received: from smtp.gentoo.org (smtp.gentoo.org [140.211.166.183]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id AD6A321C038 for ; Tue, 9 Aug 2016 10:06:31 +0000 (UTC) Received: from katipo2.lan (unknown [IPv6:2406:e001:1:d01:c2f8:daff:fe83:ed01]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) (Authenticated sender: kentnl) by smtp.gentoo.org (Postfix) with ESMTPSA id AD4533409C8 for ; Tue, 9 Aug 2016 10:06:29 +0000 (UTC) Date: Tue, 9 Aug 2016 22:05:45 +1200 From: Kent Fredric To: gentoo-project@lists.gentoo.org Subject: Re: [gentoo-project] Call for agenda items - Council meeting 2016-08-14 Message-ID: <20160809220545.6f1c7dd3@katipo2.lan> In-Reply-To: References: <2e11e445-c25b-b7f2-def1-99aed92308b6@gentoo.org> <20160804162443.GA7048@whubbs1.gaikai.biz> <20160804231224.7b7462168f1d23e88fe4135c@gentoo.org> <20160804222234.GA8357@whubbs1.gaikai.biz> <20160805022658.GA15727@linux1> <20160805142859.GA19008@linux1> <20160805153658.GA11058@whubbs1.gaikai.biz> <52993bd4-afc9-197e-acda-96db413e6608@gentoo.org> <20160809173255.0ddfa090@katipo2.lan> Organization: Gentoo X-Mailer: Claws Mail 3.13.2 (GTK+ 2.24.30; x86_64-pc-linux-gnu) Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Project discussion list X-BeenThere: gentoo-project@lists.gentoo.org Reply-To: gentoo-project@lists.gentoo.org MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; boundary="Sig_/6dEcILTE5=RPygXa2K1Hand"; protocol="application/pgp-signature" X-Archives-Salt: f9edfb3f-2435-486b-b669-8b38ac89e583 X-Archives-Hash: 1c939bc20ae117180be8deaf3df63b42 --Sig_/6dEcILTE5=RPygXa2K1Hand Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable On Tue, 9 Aug 2016 01:59:35 -0400 Rich Freeman wrote: > While I think your proposal is a great one, I think this is actually > the biggest limitation. A lot of our packages (most?) don't actually > have tests that can be run on every build (most don't have tests, some > have tests that take forever to run or can't be used on a clean > install). IMHO, That's not "ideal", but we don't need idealism to be useful here. Tests passing give one kind of useful kind of quality test. But "hey, it compiles" gives useful data in itself. By easy counter example, "it doesn't compile" is in itself useful information ( and the predominant supply of bugs filed are compilation failures ). Hell, sometimes I hit a compile failure and I just go "eeh, I'll look into it next week". How many people are doing the same? The beauty of the automated datapoint is it doesn't have to be "awesome quality" to be useful, its just guidance for further investigation. =20 > While runtime testing doesn't HAVE to be extensive, we do want > somebody to at least take a glance at it. Indeed, I'm not hugely in favour of abolishing manual stabilization entirely, but sometimes it just gets to a point where its a bit beyond a joke with requests languishing untouched for months. If there was even data saying "hey, look, its obvious this isn't ready for stabilization", we could *remove* or otherwise mark for postponement stabilization requests that were failing due to crowd-source metrics. This means it can also be used to focus existing stabilization efforts to reduce the number of things being thrown in the face of manual stabilizers. >=20 > If everything you're proposing is just on top of what we're already > doing, then we have the issue that people aren't keeping up with the > current workload, and even if that report is ultra-nice it is actually > one more step than we have today. The workload would only go down if > a machine could look at the report and stabilize things without input > at least some of the time. Indeed, it would require the crowd service to be automated, and the relevant usage of the data as automated as possible, and humans would only go looking at the data when interested. For instance, when somebody manually files a stable request, some watcher could run off and scour the reports in a given window and comment "Warning: Above threshold failure rates for target in last n-days, proceed with caution", and it would only enhance the existing stabilization workflow. --Sig_/6dEcILTE5=RPygXa2K1Hand Content-Type: application/pgp-signature Content-Description: OpenPGP digital signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCAAGBQJXqasWAAoJEOhUMksTZqggyjgP/00Ea6NL0VGW7uMD8HSkuF2p zLb63E6kgVU042ruBptZMySlAW9Wgw8J4rnUlvgapve0EKSTpP0Orli6Ci+/IPni 7vxQ/r3Eg//eFlJr4+cUF7LK/NUaxLI4rdXt/bqJfNGEXDlzVSGFLDfoFZFjp/4b WdpNM1PEqhMEvgwN4OvcrDP7AOIrtk5rYc/WmDOXfTnFflzd+d4WaE3FxBzEvlWZ 3pINOFtqjtQ7ktNy5ZiMnZPjmeE2kygpMdHZHBC4cCiuoPuXbof6Gy63n50gBlyK DrtM0oYnLcNT3y+S85jo753w4t4aUzVgxssYbEAbJWu6PLHnDd4/dQq48ReWvjwc n9H2Yd/ow/9anIf2I2QZCVpZfs8CGHhAnQ7dy8ku3RfrMwvV7ZB9bKQDGmymFZDM PDbAxyULvCpUAwtDVlFO6G8w09gILVOQdNGyHZb4SyZDj4d054IhsDnwAd2m5eN+ sXLynzvXPeJwandViwzX9V0cUDSlhsPCa8LRjXe4L2v3RfykF7deU2GgP8E/W1pY 8pDb+aimoupIl7jAtuU6wGX2o6wDatLR6Ds+6xqNVMnWO4P42IkNzeND02/JTfkd HJMbmPLYZW97/0GZLDCsK1bkl/4zM9v+rSeTOG4objg2xXW1VCzaqVMm4eDCOtDS soxuvcX8j/hJm0s4gUcr =i254 -----END PGP SIGNATURE----- --Sig_/6dEcILTE5=RPygXa2K1Hand--