Tom Lane wrote:
The point I think you are missing is that having something like this
will *eliminate* repetitive, boring work, namely recognizing multiple
reports of the same problem. The buildfarm has gotten big enough that
some way of dealing with that is desperately needed, else our ability
to spot infrequently-reported issues will disappear entirely.
OK. How about if we have a table of <branch, failure_stage, regex, tag,
description, start_date> plus some webby transactions for approved users
to edit this?
The wrinkle is that applying the tags on the fly is probably not a great
idea - the status page query is already in desperate need of overhauling
because it's too slow. So we'd need a daemon to set up the tags in the
background. But that's an implementation detail. Screen real estate on
the dashboard page is also in very short supply. Maybe we could play
with the background colour, so that a tagged failure had, say, a blue
background, as opposed to the red/pink/yellow we use for failures now.
Again - an implementation detail.
My biggest worry apart from maintenance (which doesn't matter that much
- if people don't enter the regexes they don't get the tags they want)
is that the regexes will not be specific enough, and so give false
positives on the tags. Then if you're looking for things that aren't
tagged you be even more likely than today to miss the outliers. Lord
knows that regexes are hard to get right - I've been using them for a
couple of decades and they've earned me lots of money, and I still get
them wrong regularly (including several cases on the buildfarm). but
maybe we need to take the plunge and see how it works.
This would be a fine SOC project - I at least won't have time to develop
it for quite some time.
cheers
andrew
---------------------------(end of broadcast)---------------------------
TIP 3: Have you checked our extensive FAQ?
http://www.postgresql.org/docs/faq
