1 |
On Tue, 9 Aug 2016 22:05:45 +1200 |
2 |
Kent Fredric <kentnl@g.o> wrote: |
3 |
|
4 |
> On Tue, 9 Aug 2016 01:59:35 -0400 |
5 |
> Rich Freeman <rich0@g.o> wrote: |
6 |
> |
7 |
> > While I think your proposal is a great one, I think this is actually |
8 |
> > the biggest limitation. A lot of our packages (most?) don't |
9 |
> > actually have tests that can be run on every build (most don't have |
10 |
> > tests, some have tests that take forever to run or can't be used on |
11 |
> > a clean install). |
12 |
> |
13 |
> IMHO, That's not "ideal", but we don't need idealism to be useful |
14 |
> here. |
15 |
> |
16 |
> Tests passing give one kind of useful kind of quality test. |
17 |
> |
18 |
> But "hey, it compiles" gives useful data in itself. |
19 |
> |
20 |
> By easy counter example, "it doesn't compile" is in itself useful |
21 |
> information ( and the predominant supply of bugs filed are compilation |
22 |
> failures ). |
23 |
> |
24 |
> Hell, sometimes I hit a compile failure and I just go "eeh, I'll look |
25 |
> into it next week". How many people are doing the same? |
26 |
> |
27 |
> The beauty of the automated datapoint is it doesn't have to be |
28 |
> "awesome quality" to be useful, its just guidance for further |
29 |
> investigation. |
30 |
> > While runtime testing doesn't HAVE to be extensive, we do want |
31 |
> > somebody to at least take a glance at it. |
32 |
> |
33 |
> Indeed, I'm not hugely in favour of abolishing manual stabilization |
34 |
> entirely, but sometimes it just gets to a point where its a bit beyond |
35 |
> a joke with requests languishing untouched for months. |
36 |
> |
37 |
> If there was even data saying "hey, look, its obvious this isn't ready |
38 |
> for stabilization", we could *remove* or otherwise mark for |
39 |
> postponement stabilization requests that were failing due to |
40 |
> crowd-source metrics. |
41 |
> |
42 |
> This means it can also be used to focus existing stabilization efforts |
43 |
> to reduce the number of things being thrown in the face of manual |
44 |
> stabilizers. |
45 |
> |
46 |
> > |
47 |
> > If everything you're proposing is just on top of what we're already |
48 |
> > doing, then we have the issue that people aren't keeping up with the |
49 |
> > current workload, and even if that report is ultra-nice it is |
50 |
> > actually one more step than we have today. The workload would only |
51 |
> > go down if a machine could look at the report and stabilize things |
52 |
> > without input at least some of the time. |
53 |
> |
54 |
> Indeed, it would require the crowd service to be automated, and the |
55 |
> relevant usage of the data as automated as possible, and humans would |
56 |
> only go looking at the data when interested. |
57 |
> |
58 |
> For instance, when somebody manually files a stable request, some |
59 |
> watcher could run off and scour the reports in a given window and |
60 |
> comment "Warning: Above threshold failure rates for target in last |
61 |
> n-days, proceed with caution", and it would only enhance the existing |
62 |
> stabilization workflow. |
63 |
|
64 |
This whole thing you are proposing has been a past stats project many |
65 |
times in GSOC for Gentoo. The last time, it produced a decent system |
66 |
that was functional and __NEVER__ got deployed and turned on. It ran |
67 |
for several years on the gentoo GSOC student server (vulture). It |
68 |
never gained traction with the infra team due to lack of infra |
69 |
resources and infra personnel to maintain it. |
70 |
|
71 |
Perhaps with the new hardware recently purchased to replace the failed |
72 |
server from earlier this year, we should have some hardware resources. |
73 |
If you can dedicate some time to work on the code which I'm sure will |
74 |
need some updating now, I would help as well (not that I already can't |
75 |
keep up with all the project coding I'm involved with). |
76 |
|
77 |
This is of course if we can get a green light from our infra team to be |
78 |
able to implement a stats vm on the new ganeti system. |
79 |
|
80 |
We will also need some help from security people to ensure the system |
81 |
is secure, nginx/lightttp configuration, etc... |
82 |
|
83 |
So, are you up for it? Any Gentoo dev willing to help admin such a |
84 |
system, please reply with your area of expertise and ability to help. |
85 |
|
86 |
Maybe we can finally get a working and deployed stats system. |
87 |
|
88 |
-- |
89 |
Brian Dolbec <dolsen> |