Gentoo Archives: gentoo-dev

From: Igor <lanthruster@×××××.com>
To: Tim Boudreau <gentoo-dev@l.g.o>
Subject: Re: [gentoo-dev] A constructive reommendation on stablity improvemt
Date: Mon, 11 Aug 2014 19:49:14
In Reply to: Re: [gentoo-dev] A constructive reommendation on stablity improvemt by Tim Boudreau
1 Hello Tim,
3 Sunday, August 10, 2014, 4:41:09 AM, you wrote:
5 I have no doubts that it could be done.
7 What I'm perplexed about...
9 The project consists of 3 major parts:
11 Reporting (portage -> Database <- Processing)
12 Database
13 Processing
15 Wouldn't it be logical to have Data Reporting unit working to some extent before everything else?
16 It's difficult to code imagining the most important part of the game - portage Reporting unit.
18 Database and Processing units both would require an expensive hardware to work, there should
19 be some kind invitation from portage to spend a few thousand bucks. Not to mention time.
21 If the invitation in Portage is there a lot of people can try out their own Database and Processing
22 units. Sounds fair to me.
25 FWIW: I have worked on a project for years where exception reporting was used as a "pump handle" for Bugzilla. It can be done; the trick is getting good data *in* and automating recognition of which failures are the same failure, doing NOTHING until some threshold number of failures are logged, and having a way to flag certain flavors of report as known-bogus. Here is an example failure report and resulting bug report:
30 That being said, it was done for ONE language in ONE application, where the error messages were detailed, meaningful and in a standard, Java-specific format.
32 Doing that across the multiple languages, myriad bug tracking systems (including none at all), for all packages anyone ever might build on Linux sounds like a doomed enterprise. I'm not saying don't do it - such statistics might be interesting in aggregate - but don't have high hopes for it solving the world's problems, and plan on simply publishing those stats in a consumable way, promote their existence and plan on *attracting* developers and projects to *want* to consume those, as opposed to force-feeding every bug tracker in the universe, which I assure you, will not win friends.
34 But the bottom line is: Write a patch. Prototype the server-side piece. People respond to working code; hypothetical discussions about what somebody else could or should do inevitably go nowhere. If you write something, nobody can say you're not committed to it, and *everybody* will agree on what the thing does because they can see it, rather than guessing at what "files a bug report" means and getting into arguments because people are using the same words for different things. You'll probably get a better sense of the problem space and what's easy and what's hard about it in the process, which will result in a better proposal.
36 If it's just telling other people what they ought to do, then it looks like you're a dilettante, and people are rightly wary of that.
38 -Tim
44 --
45 Best regards,
46 Igor mailto:lanthruster@×××××.com