Charles Plessy <plessy@debian.org> (06/08/2009): > So to summarise, you are suggesting me to write upstream that: > > 1) We want to review their patches, > 2) We can not do this with context diffs, > 3) We do want to actively reject non-unified diffs despite our tools work well with them, Sure. > 4) The reason why they should adopt a new diff format is because it is new. It *was*. 20 years ago. > May I have some evidence that somebody really wants to review their > patch? Any NMUer, any QA folks, any security-team guy, etc. Guess what? A package can have a lot of eyes going over it, that don't belong to the Maintainer/Uploaders. > As I explained already, it is not a random patch grabbed from their > BTS, it is their standard way to publish official corrections that > change a few lines in an archive of 20 Mo. AHAHAH. Want to talk about amule again? If that was still needed, that's a *very* good reason to check what upstream does, especially when it comes to security. And having *context* when it comes to a *20MB* (you used the French unit, FWIW, just to clarify to other readers) *might* be a very good idea. > What is next? Will the Project decide a standard whitespace policy and > nitpick every upstream project that does not respect it? Delirium Tremens? Unified diffs are not about whitespace-only changes, as you were already explained. > The only patch review system I know in Debian works well with context > diffs (http://patch-tracking.debian.net/package/emboss/6.1.0-2). > Quilt, patch, diffstat, all work well with context diff. dpkg-dev > itself works well with context diffs. You probably don't want to list each and every stuff for which we keep some sort of backward-compatibility. Or you should probably get started. > The only reason it fails is that there is a political decision to > reject non-unified diffs. Sure. Oh, if you really need an example, what about the following? We tend to fix GCC issues. We tweak headers. Some might get added, some might be removed. We have such a patch. A CVE arrives. A context diff gets published. It gets applies on the top of the other patches. Say it's something like: | > BUGON(my_pointer_shall_not_be_null); But, since we tweak the headers, the check can get added before the first dereferencement. Of course, there are the fuzzy stuff with patch, but sounds less likely to happen. Of course, that's only about politics and victimization. Mraw, KiBi.
Attachment:
signature.asc
Description: Digital signature