Norbert Preining <prein...@logic.at> writes: > Is there a rational behind not allowing any fuzz?
Fuzz indicates that the source file has changed since the patch has been generated, which means that the patch may no longer apply properly. Fuzz is a guess of convenience by the patch program that the result is *probably* what was intended. But fuzz indicates there may be a problem; for example, I've seen patches apply with fuzz that add duplicate lines to a file (because the lines were added upstream in a different location), resulting in everything from compilation errors to serious hidden bugs in the program. Therefore, I think it makes sense to require the maintainer to confirm that, yes, the patch applied with fuzz still makes the correct change and isn't indicative of an error. A good way to indicate that is to unfuzz the patch. -- Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/> -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87liku0y9w....@windlord.stanford.edu
