Re: [gentoo-dev] A constructive reommendation on stablity improvemt

[Igor <lanthruster@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 2960 bytes --]

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:lanthruster@gmail.com

[-- Attachment #2: Type: text/html, Size: 4175 bytes --]