Hello Tim, Sunday, August 10, 2014, 4:41:09 AM, you wrote:
I have no doubts that it could be done. What I'm perplexed about... The project consists of 3 major parts: Reporting (portage -> Database <- Processing) Database Processing Wouldn't it be logical to have Data Reporting unit working to some extent before everything else? It's difficult to code imagining the most important part of the game - portage Reporting unit. Database and Processing units both would require an expensive hardware to work, there should be some kind invitation from portage to spend a few thousand bucks. Not to mention time. If the invitation in Portage is there a lot of people can try out their own Database and Processing units. Sounds fair to me. 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: http://statistics.netbeans.org/exceptions/detail.do?id=205871 https://netbeans.org/bugzilla/show_bug.cgi?id=239261 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. 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. 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. 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. -Tim -- Best regards, Igor mailto:[email protected]
