Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 20 Jan 2003 11:19:48 -0600
From:      Mark Linimon <linimon@lonesome.com>
To:        Edwin Groothuis <edwin@mavetju.org>
Cc:        ports@freebsd.org
Subject:   Re: Bento Reporting Enhancements
Message-ID:  <200301201119.48113.linimon@lonesome.com>
In-Reply-To: <20030120132715.GA27491@k7.mavetju>
References:  <20030120132715.GA27491@k7.mavetju>

next in thread | previous in thread | raw e-mail | index | archive | help
I have been working on some technology that I think could well
lend itself to solving this exact problem.  (It is currently up for
submission to Kris).  Interested parties should take a look at the
prototype on http://lonesome.dyndns.org/bento/errorlogs/newindex.html.
There they'll find reports that detail all current ports-related build
errors by build enviroment (defined as architecture * OS release),
all build errors by build environment, all ports PRs by portname,
and the grand summary of (latest unique build error and ports PRs)
by portname.

All of this code is based in Python and released under the BSD
license.  I've been working on it for a few weeks now.

It is not *currently* based on a database; however, the data
gathering/data mining function is fairly well separated from the
data reporting functions.  (As always, as hacks evolve, it
could use a little work, but ...)  One of the TODOs includes
making a database out of it.  Since I've spent my last 5 years'
career time writing database code, I might well be a natural
for this task :-)

Taking the existing code and making the data queries into
SQL queries would be the first step.  This would also allow
creation of a cgi page to allow queries into the complete
data space of (portname vs build errors vs build environment
vs PRs).  This cgi page could also include dates, maintainers,
PR state, and other interesting things.  Adding effective-dated
tables that mirrored the simpler tables would not be a much
more difficult step (and that's what I think Edwin is looking
for in his initial message).

In terms of performance, even without the database the rate-
limiting step is trying to grovel over the raw GNATS PRs to
find out which port they each apply to :-)  This would be best
done once for the existing GNATS database, and then once
per PR as new ones come in.

I think this would be interesting work to do, especially the
part that watched the CVS logs and incoming PR changes,
as that would allow me to work on some things I've not
done before.

Also see my PRs www/44919 and www/47194 that attempt to
greatly reduce the number of build errors reported as '???'.
AFAIK these change go hand-in-hand with the above code.
(You can see the difference these make by looking at the
"built on local" links on the above page).

(btw, ignore my www/46500, it is obsoleted by the work
mentioned above and should be closed.)

I welcome comments and further thoughts.

mcl


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-ports" in the body of the message




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200301201119.48113.linimon>