Jonathan Nieder <jrnieder@xxxxxxxxx> writes: >> I am sympathetic to the cause and I agree that introducing a >> finer-grained classification might be a solution. I however am not >> sure how we can enforce developers to apply such a manually assigned >> "error code" cosistently. > > I think two things you're hinting at are "what about maintainability?" > and "what is the migration path?" Not really. There is not much to migrate from, and mislabeling by developers, or more realistically disagreement between developers what label is appropriate for which condition that leads to die(), would be a usability problem and not maintainability that I would be worried about. > However, for analysis in aggregate (for example, to define an SLO[1]) > that would require us to maintain a database that maps > <filename>:<lineno> to error code. That database would be essentially > the same as patches to record the error codes, so what it would really > amount to is having these deployments using a permanent fork of Git. Yes, the suggestion was to start from there to gain experience, because ... > If we expect the error codes to not be useful to anyone else, then > that is the right choice to make (or rather, we'd have to use other > heuristics, such as having the traces record a collection of offsets > in the binary and a build-id so we can key off of stack trace > signatures). Part of the reason I started this thread is to get a > sense of whether these can be useful to others. ... others will find it useful if the classification matches _their_ needs, but I suspect the "bin" a single die() location wants to be classfied into would end up to be different depending on what the log collecting entity is after.
