From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from lists.gentoo.org (pigeon.gentoo.org [208.92.234.80]) by finch.gentoo.org (Postfix) with ESMTP id 828CB13877A for ; Mon, 11 Aug 2014 19:49:14 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id ECC19E09DC; Mon, 11 Aug 2014 19:49:08 +0000 (UTC) Received: from mail-la0-f51.google.com (mail-la0-f51.google.com [209.85.215.51]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id 6D9EFE09CD for ; Mon, 11 Aug 2014 19:49:07 +0000 (UTC) Received: by mail-la0-f51.google.com with SMTP id pn19so7060324lab.38 for ; Mon, 11 Aug 2014 12:49:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:reply-to:to:subject:in-reply-to:references :mime-version:content-type; bh=jRe7EsxAeD8aoAoXD6CED+LcRf8EaSO0X3sdkwnGEAI=; b=sZvETzmdN94Z4hDKeaT91Ja1gTEyEI4kcSGeoYPJYQKSkouVQqnLE5ms0fB3QcKk9o RakfaVBdZ7/ujx+s0IQUFVqHcAHOsU7Jry6aCy/F8ayAGPG4czk4XdbgMlrXjJNhbEtY Z6yN54eO0S97DySgMrdc8GHEoAFRuWFUJMwiDSFGNiAXLXUxF7FRR7HQVLt9hkO674NV imr6DLD6zAjOb34PRiCfxoVsD8OM2pT6bwpWMb/xiUzJj9FXBECdDBFpAUzL+Ex9x5Ck t9jsdi8kae5QUXP+hLkRSZXCn8EUTrAMVpDuVFGq3QWDr4JRxK7V8XNBmVxdgqdNMsfZ EnGw== X-Received: by 10.152.207.36 with SMTP id lt4mr3939111lac.72.1407696834904; Sun, 10 Aug 2014 11:53:54 -0700 (PDT) Received: from [192.168.60.64] (office.healtech.ru. [89.208.21.2]) by mx.google.com with ESMTPSA id ue8sm4955198lac.31.2014.08.10.11.53.53 for (version=TLSv1 cipher=RC4-SHA bits=128/128); Sun, 10 Aug 2014 11:53:53 -0700 (PDT) Message-ID: <53e7bfc1.88ea980a.774f.67ba@mx.google.com> X-Google-Original-Message-ID: <82507696.20140810225351@gmail.com>> Date: Sun, 10 Aug 2014 22:53:51 +0400 From: Igor X-Priority: 3 (Normal) To: Tim Boudreau Subject: Re: [gentoo-dev] A constructive reommendation on stablity improvemt In-Reply-To: References: <53e649e6.c8a1980a.2941.4762@mx.google.com> <53e66536.240d700a.104a.477d@mx.google.com> <20140809212239.181e15f6@marga.jer-c2.orkz.net> Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-dev@lists.gentoo.org Reply-to: gentoo-dev@lists.gentoo.org MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----------0451270F81E43E7C7" X-Archives-Salt: 8dbb7d45-64a4-490e-b805-ef16fc8ff3e7 X-Archives-Hash: adcb61b4b96aa328d865944d9f28f7c0 ------------0451270F81E43E7C7 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hello Tim, Sunday, August 10, 2014, 4:41:09 AM, you wrote: I have no doubts that it could be done.=20 What I'm perplexed about...=20 The project consists of 3 major parts: Reporting (portage -> Database <- Processing)=20 Database =20 Processing Wouldn't it be logical to have Data Reporting unit working to some extent b= efore everything else? It's difficult to code imagining the most important part of the game - port= age Reporting unit. Database and Processing units both would require an expensive hardware to w= ork, there should=20 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=20 units. Sounds fair to me. FWIW: I have worked on a project for years where exception reporting was u= sed 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 f= ailure, doing NOTHING until some threshold number of failures are logged, a= nd 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=3D205871 https://netbeans.org/bugzilla/show_bug.cgi?id=3D239261 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.=20 Doing that across the multiple languages, myriad bug tracking systems (incl= uding none at all), for all packages anyone ever might build on Linux sound= s like a doomed enterprise. I'm not saying don't do it - such statistics m= ight 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 consu= mable 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 somebo= dy 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 wh= at the thing does because they can see it, rather than guessing at what "fi= les 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 o= f 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 --=20 Best regards, Igor mailto:lanthruster@gmail.com ------------0451270F81E43E7C7 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable Re: [gentoo-dev] A constructive reommendation on stablit= y improvemt 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 b= efore everything else?
It's difficult to code imagining the most important part of the game - port= age Reporting unit.

Database and Processing units both would require an expensive hardware to w= ork, 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.
http://stati= stics.netbeans.org/exceptions/detail.do?id=3D205871
https://netbeans.org/bugzill= a/show_bug.cgi?id=3D239261

That being sai= d, it was done for ONE language in ONE application, where the error message= s were detailed, meaningful and in a standard, Java-specific format. <= br>
Doing that across the multiple languages, myriad bug tracking systems (incl= uding none at all), for all packages anyone ever might build on Linux sound= s like a doomed enterprise.  I'm not saying don't do it - such statist= ics might be interesting in aggregate - but don't have high hopes for it so= lving 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-sid= e piece.  People respond to working code;  hypothetical discussio= ns 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 *ev= erybody* 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                   &= nbsp;