-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
Add
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
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
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_LEVEL
to
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 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_LEVEL
to make.conf
(several URLs should be supported
On 10 August 2014 04:18, Igor lanthrus...@gmail.com 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
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
On Sat, 9 Aug 2014 22:15:17 +0400
Igor lanthrus...@gmail.com 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
On 10 August 2014 06:15, Igor lanthrus...@gmail.com 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
On 10 August 2014 07:22, Jeroen Roovers j...@gentoo.org 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
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,
12 matches
Mail list logo
