-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 10/08/14 05:03 PM, Thomas Kahle wrote:
> Hi,
>
> On 09/08/14 18:18, Igor wrote:
>> Hi all,
>>
>> Hereby the summary of my personal suggestions to increase GENTOO
>> stability and help it's maintainers and developers.
>>
>> 1. make.conf
>>
>> A
On 09/08/14 21:22, Jeroen Roovers wrote:
> A better bug reporting client will not deal with all the problems of bad
> reports (and probably exacerbate that problem), but it will stop spam
> and should encourage users to file more bug reports, and would be
> based on a vetted implementation that has
Hi,
On 09/08/14 18:18, Igor wrote:
> Hi all,
>
> Hereby the summary of my personal suggestions to increase GENTOO stability
> and help it's maintainers
> and developers.
>
> 1. make.conf
>
>Add
>
>BUG_REPORT_URL "http://";(or similar name)
>BUG_REPORT ON/OFF
>BUG_REPORT_LE
Hello Kent,
Saturday, August 9, 2014, 11:49:43 PM, you wrote:
We have a lot of uncertainty even about what to send and how. It is
important for a data processor to understand what data is going to be fed
before it's designed.
If you have 1000 requests/second JSON parsing might be a problem and
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 work
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,
On 10 August 2014 07:22, Jeroen Roovers wrote:
>
> Example 2: Mr. I.B. User configured his system with CFLAGS=-fomg-faster
> and now it generates a ton of build failures. All of these should go
> to /dev/null, but there we are running an automated service that cannot
> be taught how to distinguis
On 10 August 2014 06:15, Igor wrote:
> Communication protocol is already there - it's HTTP, method POST
> HTTP protocol is already with Python - CURL, WGET
> A reliable server ready to accept data from portage is all so there -
> it's Apache web server.
For the sake of this discussion, those p
On Sat, 9 Aug 2014 22:15:17 +0400
Igor wrote:
> I really don't think data processing unit comes first.
The thing is, almost everything for automated build failure reporting
is in place on the client side. Build logs are automatically generated
and `emerge --info =$CATEGORY/${PF}' is easy, which
Kent,
Saturday, August 9, 2014, 9:42:18 PM, you wrote:
Thank you for your opinion.
I really don't think data processing unit comes first.
Communication protocol is already there - it's HTTP, method POST
HTTP protocol is already with Python - CURL, WGET
A reliable server ready to accept data from
On 10 August 2014 04:18, Igor wrote:
> 5. Wait for server-side implementations to appear. They will appear once
>emerge can report. And once it's clear for the rest that there is
> seriously
>going to be a change soon.
>
It really needs to be designed from the server side, not the client
11 matches
Mail list logo
