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 6A1A813832E for ; Wed, 10 Aug 2016 01:15:42 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id C5E1921C0AB; Wed, 10 Aug 2016 01:15:38 +0000 (UTC) Received: from mail-ua0-f169.google.com (mail-ua0-f169.google.com [209.85.217.169]) (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 32C7621C0A2 for ; Wed, 10 Aug 2016 01:15:38 +0000 (UTC) Received: by mail-ua0-f169.google.com with SMTP id k90so47435141uak.1 for ; Tue, 09 Aug 2016 18:15:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=1IlQfPsm9Gn0KUThBdYT9KnMfS8HDi2aYo0O1BkrZAY=; b=wDxehnlHB1bZs4Lnu+vynStAfMueHO/t+p1/idBZaaalfQWkRJdHeBV36RGeaUdUUo FDaWU9eI1uLhGMZaolaqLpGWfcpWTAnXG3NdIOru90AfPYFscU2f1gCkchrynAqBG50g dWmJqW3aoSxpxjba2Z8TDfV2z7TylN1SciHYGng318m9l2t1gdaATHhgeEVmuiTZLAcu 2txB8yQwbXhWV2LzQLSQgnCh0bPuAHDXFiKg16Re/Q2WwgVVG6eTl5lcyJXtDdKEQZFK ckZdw5fGr/ABVIctqUzVcUvf+xnUFcI5Gsz0uz1D585ordaDPTVLaeoyciWg5ZrVgduX J4xQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=1IlQfPsm9Gn0KUThBdYT9KnMfS8HDi2aYo0O1BkrZAY=; b=XzV6xM4VZNgX9J2pBYckCQK2tDUbydL0rGHIWaSDRy+RGeIjyny9ZRa70jVhrAY7Z9 lV6o0aF2Ecug6LSVFdRo6P/7hcSFqXRw8kK8fmTueE+qxqW9Qq9ea9+iBAQcwe9g5Lfp Rhxh+3S244U4qf+WqNHMeq6UsPK0M79rjo4LWgte2T+JroOIT+A+NTgxVYdPkgoKkwAF +P+c2v/NOkbzaf41ZzOVVtRaFJHX2VNoiA6seFIeJ8y+pKb3LjjRi7HhWXCqm4IQgTtd xZX18ctnnSueYAMFTANHzS0fiG/AeOJ8wwXgIK8vln2/LOgoWEQ2tdG0dv1h2Zq5ov9T TwIA== X-Gm-Message-State: AEkoout+m85BQ+HSnlmOqHqozapYSjstW6kmhsmELuqFRmAKqE4bxpVjaoWEYqDOi6WFtYJ7vc4DEIbZhZrIWg== X-Received: by 10.31.47.207 with SMTP id v198mr646147vkv.109.1470791737085; Tue, 09 Aug 2016 18:15:37 -0700 (PDT) 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 Received: by 10.176.64.69 with HTTP; Tue, 9 Aug 2016 18:15:16 -0700 (PDT) In-Reply-To: <20160809074105.37e9ba17.dolsen@gentoo.org> 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> <20160809074105.37e9ba17.dolsen@gentoo.org> From: Pallav Agarwal Date: Wed, 10 Aug 2016 06:45:16 +0530 Message-ID: Subject: Re: [gentoo-project] Call for agenda items - Council meeting 2016-08-14 To: gentoo-project@lists.gentoo.org Content-Type: multipart/alternative; boundary=001a114336bc0716600539ad631c X-Archives-Salt: 8cb6a97c-eede-4033-8759-bda28567a6b9 X-Archives-Hash: 762e0ca46568aba39151d578e599a851 --001a114336bc0716600539ad631c Content-Type: text/plain; charset=UTF-8 On Tue, Aug 9, 2016 at 8:11 PM, Brian Dolbec wrote: > On Tue, 9 Aug 2016 22:05:45 +1200 > Kent Fredric wrote: > > > 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. > > > 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. > > > > > > > > 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. > > 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). > > 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. > > -- > Brian Dolbec > > The similar GSoC project this year is in fact my project, named [Continuous Stabilization]. I would be very interested to know what I can do to ensure that the system is deployed and used this time. --001a114336bc0716600539ad631c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On T= ue, Aug 9, 2016 at 8:11 PM, Brian Dolbec <dolsen@gentoo.org>= wrote:
On Tue, 9 Aug 2016 22:05:45 +1200
Kent Fredric <kentnl@gentoo.org= > wrote:

> On Tue, 9 Aug 2016 01:59:35 -0400
> Rich Freeman <rich0@gentoo.org<= /a>> wrote:
>
> > While I think your proposal is a great one, I think this is actua= lly
> > the biggest limitation.=C2=A0 A lot of our packages (most?) don&#= 39;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 u= sed 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 itse= lf 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 furthe= r
> investigation.
> > While runtime testing doesn't HAVE to be extensive, we do wan= t
> > somebody to at least take a glance at it.
>
> Indeed, I'm not hugely in favour of abolishing manual stabilizatio= n
> 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= 9;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.
>
> >
> > 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 w= ith the
> > current workload, and even if that report is ultra-nice it is
> > actually one more step than we have today.=C2=A0 The workload wou= ld only
> > go down if a machine could look at the report and stabilize thing= s
> > 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<= br> > 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 las= t
> n-days, proceed with caution", and it would only enhance the exis= ting
> stabilization workflow.

This whole thing you are proposing has been a past stats projec= t many
times in GSOC for Gentoo.=C2=A0 The last time, it produced a decent system<= br> that was functional and __NEVER__ got deployed and turned on.=C2=A0 It ran<= br> for several years on the gentoo GSOC student server (vulture).=C2=A0 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<= br> keep up with all the project coding I'm involved with).

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?=C2=A0 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.

--
Brian Dolbec <dolsen>


The s= imilar GSoC project this year is in fact my project, named
[Continuous = Stabilization]. I would be very interested to know what I
can do to ensu= re that the system is deployed and used this time.
--001a114336bc0716600539ad631c--