1 |
Hello Tim, |
2 |
|
3 |
Sunday, August 10, 2014, 4:41:09 AM, you wrote: |
4 |
|
5 |
I have no doubts that it could be done. |
6 |
|
7 |
What I'm perplexed about... |
8 |
|
9 |
The project consists of 3 major parts: |
10 |
|
11 |
Reporting (portage -> Database <- Processing) |
12 |
Database |
13 |
Processing |
14 |
|
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. |
17 |
|
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. |
20 |
|
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. |
23 |
|
24 |
|
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: |
26 |
|
27 |
http://statistics.netbeans.org/exceptions/detail.do?id=205871 |
28 |
https://netbeans.org/bugzilla/show_bug.cgi?id=239261 |
29 |
|
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. |
31 |
|
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. |
33 |
|
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. |
35 |
|
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. |
37 |
|
38 |
-Tim |
39 |
|
40 |
|
41 |
|
42 |
|
43 |
|
44 |
-- |
45 |
Best regards, |
46 |
Igor mailto:lanthruster@×××××.com |