> In the first case we could easily mitigate the risk by testing and be fairly
> confident, in the second case the tests are too complex to achieve the same
> confidence and we should take this kind of risk only if there were a serious
> benefit to balance it, but in this case, there are other s
Hi,
So some of the arguments here is that we are introducing risk for
something that is not really a big problem. Or, simply not worth
investing in. From a Red Hat perspective "we" would _never_ fix this,
it's just not a problem that comes up enough to justify the work and
time. But... The
Hi William,
Things are not black and white:
there is a huge difference between a fix with limited impact (like
adding some check in configuration tools or in the server) and redesigning
something that is used in many different contexts for every request handled
by the server ...
In the first c
