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.



---------------------------(end of broadcast)---------------------------
TIP 3: Have you checked our extensive FAQ?


Reply via email to