| 1 |
FWIW: I have worked on a project for years where exception reporting was |
| 2 |
used as a "pump handle" for Bugzilla. It can be done; the trick is |
| 3 |
getting good data *in* and automating recognition of which failures are the |
| 4 |
same failure, doing NOTHING until some threshold number of failures are |
| 5 |
logged, and having a way to flag certain flavors of report as known-bogus. |
| 6 |
Here is an example failure report and resulting bug report: |
| 7 |
|
| 8 |
http://statistics.netbeans.org/exceptions/detail.do?id=205871 |
| 9 |
https://netbeans.org/bugzilla/show_bug.cgi?id=239261 |
| 10 |
|
| 11 |
That being said, it was done for ONE language in ONE application, where the |
| 12 |
error messages were detailed, meaningful and in a standard, Java-specific |
| 13 |
format. |
| 14 |
|
| 15 |
Doing that across the multiple languages, myriad bug tracking systems |
| 16 |
(including none at all), for all packages anyone ever might build on Linux |
| 17 |
sounds like a doomed enterprise. I'm not saying don't do it - such |
| 18 |
statistics might be interesting in aggregate - but don't have high hopes |
| 19 |
for it solving the world's problems, and plan on simply publishing those |
| 20 |
stats in a consumable way, promote their existence and plan on *attracting* |
| 21 |
developers and projects to *want* to consume those, as opposed to |
| 22 |
force-feeding every bug tracker in the universe, which I assure you, will |
| 23 |
not win friends. |
| 24 |
|
| 25 |
But the bottom line is: Write a patch. Prototype the server-side piece. |
| 26 |
People respond to working code; hypothetical discussions about what |
| 27 |
somebody else could or should do inevitably go nowhere. If you write |
| 28 |
something, nobody can say you're not committed to it, and *everybody* will |
| 29 |
agree on what the thing does because they can see it, rather than guessing |
| 30 |
at what "files a bug report" means and getting into arguments because |
| 31 |
people are using the same words for different things. You'll probably get |
| 32 |
a better sense of the problem space and what's easy and what's hard about |
| 33 |
it in the process, which will result in a better proposal. |
| 34 |
|
| 35 |
If it's just telling other people what they ought to do, then it looks like |
| 36 |
you're a dilettante, and people are rightly wary of that. |
| 37 |
|
| 38 |
-Tim |
Archives