This is why a bug is reported, when it is patched, the bug will be closed. This is the point of a bug tracker in a free software project: document the current issues that need to be solved or improved.

Well the patch certainly met Intel's needs (a nice little performance bump over its ascendant rival) ... and since someone with a keen eye spotted it, now the rest of us can submit a patch to correct that. But I'm not sure that a back-and-forth war of self-serving patches is very productive or serves anyone very well.

In this scenario, is not each self-serving patch strictly an improvement? It's at least arguable that a back-and-forth competition to provide improvements serves everyone well.

> But I'm not sure that a back-and-forth war of self-serving patches is very productive or serves anyone very well.

In large FOSS projects you have enough eyes on those patches to ensure they actually converge towards some (unbiased) optimum.

That's a myth. When was the last time you reviewed the technical aspect of heavily specific platform code in the glibc ?

about 3 months ago, in a code audit.