Gentoo Archives: gentoo-dev

From: Jeroen Roovers <jer@g.o>
To: gentoo-dev@l.g.o
Subject: Re: [gentoo-dev] A constructive reommendation on stablity improvemt
Date: Sat, 09 Aug 2014 19:22:52
In Reply to: Re: [gentoo-dev] A constructive reommendation on stablity improvemt by Igor
1 On Sat, 9 Aug 2014 22:15:17 +0400
2 Igor <lanthruster@×××××.com> wrote:
4 > I really don't think data processing unit comes first.
6 The thing is, almost everything for automated build failure reporting
7 is in place on the client side. Build logs are automatically generated
8 and `emerge --info =$CATEGORY/${PF}' is easy, which is what we already
9 require for bug reports.
11 Uploading two files to a web server is trivial viewed from the client
12 side.
14 > Communication protocol is already there - it's HTTP, method POST
15 > HTTP protocol is already with Python - CURL, WGET
16 > A reliable server ready to accept data from portage is all so there -
17 > it's Apache web server.
19 That's a matter of implementation. It doesn't concern the design, which
20 is what you want to be dealing with right now.
22 > What we don't have to start with portage class is just a number of
23 > parameters to submit.
25 Yes, we do. See above. Improvements are suggested and implemented from
26 time to time (see perhaps bug #436294).
28 > Once the list is ready -> add it reporter to portage -> and the
29 > server side data processing unit will appear.
31 Processing what?
33 Example 1: Dr. A. Spammer wants to reach Gentoo developers because he
34 wants to sell them stuff, marry them or give them ONE MILLION DOLLARS.
35 He can spam mailing lists and aliases but they have spam filters or
36 require subscriptions or both. Or he can trivially upload his spam to
37 the build failure log processing server, which will do all the work of
38 distributing those "bug reports".
40 The problem: How do you propose to keep that new service clean? We'd
41 need a spam filter and user authentication, which is a lot harder to do
42 on the client side (than merely uploading to an open server) and
43 requires proper user management on the server side too, which comes
44 with security concerns and manual involvement.
46 Example 2: Mr. I.B. User configured his system with CFLAGS=-fomg-faster
47 and now it generates a ton of build failures. All of these should go
48 to /dev/null, but there we are running an automated service that cannot
49 be taught how to distinguish between genuine bug reports and PEBKAC.
51 The problem: How do you propose to filter out all the junk and promote
52 genuine issues to "bug reports"?
54 Both examples should make clear why we have a bug tracker and not an
55 automated build failure reporting facility - it works rather well and
56 it stops dead a lot of spam and bad reports.
58 It currently takes a handful of people a lot of dedication and time to
59 weed out the crappy bug reports (support requests, misconfiguration,
60 out of date packages, duplicates) from the real ones, but since filing
61 bug reports takes an actual effort by the reporter, we probably don't
62 see that many bad ones.
64 With an automated build failure service in place, we should be prepared
65 to start manually processing an order of magnitude more reports and
66 still decide intelligently which are good and which aren't. Without a
67 really good interface (and a larger team of people dedicated to that
68 job), people will probably start ignoring the entire thing pretty
69 quickly.
71 Creating a better (command line) interface to bugzilla.g.o is probably
72 what we should be working on: extend pybugz (and the server side API)
73 somewhat and create a simple UI that asks some additional questions
74 (about steps to reproduce, a useful Summary/Description and so on) and
75 automatically submits that information. If a user wants to, he can then
76 flip a FEATURES switch which will automatically invoke that bugzilla
77 client, feeding it some preliminary information and a couple of files
78 to attach.
80 A better bug reporting client will not deal with all the problems of bad
81 reports (and probably exacerbate that problem), but it will stop spam
82 and should encourage users to file more bug reports, and would be
83 based on a vetted implementation that has already addressed many of
84 the concerns that your proposal would need to address from the ground
85 up.
88 jer