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 34A8613832E for ; Tue, 9 Aug 2016 14:41:19 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id C4AC6E0B08; Tue, 9 Aug 2016 14:41:16 +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 1EC57E0B07 for ; Tue, 9 Aug 2016 14:41:16 +0000 (UTC) Received: from professor-x (S010634bdfa9ecf80.vc.shawcable.net [96.49.31.57]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) (Authenticated sender: dolsen) by smtp.gentoo.org (Postfix) with ESMTPSA id A7B53340861 for ; Tue, 9 Aug 2016 14:41:14 +0000 (UTC) Date: Tue, 9 Aug 2016 07:41:05 -0700 From: Brian Dolbec To: gentoo-project@lists.gentoo.org Subject: Re: [gentoo-project] Call for agenda items - Council meeting 2016-08-14 Message-ID: <20160809074105.37e9ba17.dolsen@gentoo.org> In-Reply-To: <20160809220545.6f1c7dd3@katipo2.lan> 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> <20160809220545.6f1c7dd3@katipo2.lan> Organization: Gentoo 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-sha512; boundary="Sig_/MKHrBSC+k/qDnm.r=6uUEso"; protocol="application/pgp-signature" X-Archives-Salt: 0070aeb2-22c7-4e77-b175-fffbde3000a0 X-Archives-Hash: 6cce17b6e6235a94432e5a150149ccac --Sig_/MKHrBSC+k/qDnm.r=6uUEso Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable On Tue, 9 Aug 2016 22:05:45 +1200 Kent Fredric wrote: > On Tue, 9 Aug 2016 01:59:35 -0400 > Rich Freeman wrote: >=20 > > 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). =20 >=20 > IMHO, That's not "ideal", but we don't need idealism to be useful > here. >=20 > Tests passing give one kind of useful kind of quality test. >=20 > But "hey, it compiles" gives useful data in itself. >=20 > By easy counter example, "it doesn't compile" is in itself useful > information ( and the predominant supply of bugs filed are compilation > failures ). >=20 > 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? >=20 > 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. =20 >=20 > 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. >=20 > 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. >=20 > 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 > >=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. =20 >=20 > 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. >=20 > 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. This whole thing you are proposing has been a past stats project many times in GSOC for Gentoo. The last time, it produced a decent system that was functional and __NEVER__ got deployed and turned on. It ran for several years on the gentoo GSOC student server (vulture). It never gained traction with the infra team due to lack of infra resources and infra personnel to maintain it. Perhaps with the new hardware recently purchased to replace the failed server from earlier this year, we should have some hardware resources. If you can dedicate some time to work on the code which I'm sure will need some updating now, I would help as well (not that I already can't keep up with all the project coding I'm involved with). =20 This is of course if we can get a green light from our infra team to be able to implement a stats vm on the new ganeti system. We will also need some help from security people to ensure the system is secure, nginx/lightttp configuration, etc... So, are you up for it? Any Gentoo dev willing to help admin such a system, please reply with your area of expertise and ability to help. Maybe we can finally get a working and deployed stats system. --=20 Brian Dolbec --Sig_/MKHrBSC+k/qDnm.r=6uUEso Content-Type: application/pgp-signature Content-Description: OpenPGP digital signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.1 iQJ8BAEBCgBmBQJXqeuBXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRBNUQ3Qzc0RTA4MUNDNzBEQjRBNEFBRjVG QkJEMDg3Mjc1ODIwRUQ4AAoJEPu9CHJ1gg7Y5bEP/Aq5jutZpijZULymQaRpIc4J 07ss+lIR35qACnwf3YdAlWLBEQCgAutrmEOmcp9fub1bMEAfBqfBgCxumcb8IUk/ GKR4jZHgeV/q/EiXkFXS2ICAQ4CunpasSCQC0zTWp0Wi5O4ZgNdg/sL8qYr3XOP0 oPV0VNNjv4s6IGAvtrAR4dsiRZF9U7eBWTT/5RCH0Txy6ElVbYffySFohGHRqUSE UJkpoTT3yhM0XNgPOfT6T+DYZlkQmIbaQBeqXDqXdA8avuF18K7Z+lu5hACk03B3 AcoSk6qc2w/BLGzKK3aWb8rWe2xxwYxUh+5FMdLsKEvfz1do+XpOTkv64hqrxipm L5jTEjmd5KfLQvnxfvrxeaFJfBFZ5sSx/zl3kZnC0l1OKhIJgexuc3P+3z/AvTXH CmVDiwhYnx5Jo7/6GnNT65yrH2jufRRzU6WORyVpCw2xS/BqQmmI6jU43R4RHBEw UfwhNWvAXEGCMJLKa45DANn8XtxA3a8dhIPhizfsF1WGzneR2I4FbKfiUNaTzMf8 WMjE+rcpTWnNw1wp0Mx6cW+HX+cWjwxGpNE68bKnQbj/ZXfwt/9zd7JAo0AJLgW3 Wq9Qen3PAG/8IgDSIYOVJaHCu2M7A9vF1uc0ET5IWIZYznxlE1ZHV59grnRI41GW mYJjhAG3U8z0iflzekA0 =Hdnv -----END PGP SIGNATURE----- --Sig_/MKHrBSC+k/qDnm.r=6uUEso--