Re: raw headers in rfc822.Message
Zack Weinberg writes:
You've generated this patch backward, and in a format which makes it useless to us. Please regenerate it with diff -c or diff -u (either is acceptable) and put the newer file _second_ on the command line: diff -u OLD_FILE NEW_FILE.
It wasn't all that long ago that I submitted my first patch (of documentation, not code) to SourceForge. It took me > 20 minutes of careful web searching to figure out the desired way of submitting files and the correct way to generate that. And I still wasn't 100% sure I was generating the diff in the correct direction. Couldn't Zack's comment be added to the directions found at https://sourceforge.net/tracker/?func=add&group_id=5470&atid=305470 so that anyone submitting a patch would see how to do it. (But of course that wouldn't have helped THIS person, who didn't use sourceforge... :-( ) -- Michael Chermside
Zack Weinberg writes:
You've generated this patch backward, and in a format which makes it useless to us. Please regenerate it with diff -c or diff -u (either is acceptable) and put the newer file _second_ on the command line: diff -u OLD_FILE NEW_FILE.
[Michael Chermside]
It wasn't all that long ago that I submitted my first patch (of documentation, not code) to SourceForge. It took me > 20 minutes of careful web searching to figure out the desired way of submitting files and the correct way to generate that. And I still wasn't 100% sure I was generating the diff in the correct direction.
Couldn't Zack's comment be added to the directions found at https://sourceforge.net/tracker/?func=add&group_id=5470&atid=305470 so that anyone submitting a patch would see how to do it.
I guess we're assuming that even people who aren't familiar with SourceForge are familiar with diff. Is that not a reasonable assumption any more? There's also the developer FAQ, which has carefull instructions for patch generation at http://www.python.org/dev/devfaq.html#patches and in addition points to http://www.python.org/patches/ which has everything you need (except the hint about forward diffs; I'll add that). --Guido van Rossum (home page: http://www.python.org/~guido/)
On Tuesday, September 10, 2002, at 04:26 , Guido van Rossum wrote:
Couldn't Zack's comment be added to the directions found at https://sourceforge.net/tracker/?func=add&group_id=5470&atid=305470 so that anyone submitting a patch would see how to do it.
I guess we're assuming that even people who aren't familiar with SourceForge are familiar with diff. Is that not a reasonable assumption any more?
Not cross-platform. I've had patches for MacPython in rather outlandish diff-like formats, so a note that tells people to use the unix diff program wouldn't hurt. -- - Jack Jansen <Jack.Jansen@oratrix.com> http://www.cwi.nl/~jack - - If I can't dance I don't want to be part of your revolution -- Emma Goldman -
I guess we're assuming that even people who aren't familiar with SourceForge are familiar with diff. Is that not a reasonable assumption any more?
Not cross-platform. I've had patches for MacPython in rather outlandish diff-like formats, so a note that tells people to use the unix diff program wouldn't hurt.
But what good does a reference to "the unix diff program" do a Mac developer? --Guido van Rossum (home page: http://www.python.org/~guido/)
On dinsdag, september 10, 2002, at 04:41 , Guido van Rossum wrote:
I guess we're assuming that even people who aren't familiar with SourceForge are familiar with diff. Is that not a reasonable assumption any more?
Not cross-platform. I've had patches for MacPython in rather outlandish diff-like formats, so a note that tells people to use the unix diff program wouldn't hurt.
But what good does a reference to "the unix diff program" do a Mac developer?
At the very least they won't send me MPW diffs. At best they fire up OSX and use the One True Diff:-) -- - Jack Jansen <Jack.Jansen@oratrix.com> http://www.cwi.nl/~jack - - If I can't dance I don't want to be part of your revolution -- Emma Goldman -
On Tue, Sep 10, 2002, Guido van Rossum wrote:
There's also the developer FAQ, which has carefull instructions for patch generation at
http://www.python.org/dev/devfaq.html#patches
and in addition points to http://www.python.org/patches/ which has everything you need (except the hint about forward diffs; I'll add that).
Perhaps the "patches" link at http://www.python.org/ should point at either DevFAQ#patches or the patches page. (That was my original intention in not linking directly to SF -- you're the one who added the direct links.) The question IMO is whether those links are for the benefit of core developers or newbies. I'm +1 on the latter. -- Aahz (aahz@pythoncraft.com) <*> http://www.pythoncraft.com/ Project Vote Smart: http://www.vote-smart.org/
From: "Guido van Rossum" <guido@python.org>
I guess we're assuming that even people who aren't familiar with SourceForge are familiar with diff. Is that not a reasonable assumption any more?
There's also the developer FAQ, which has carefull instructions for patch generation at
http://www.python.org/dev/devfaq.html#patches
and in addition points to http://www.python.org/patches/ which has everything you need (except the hint about forward diffs; I'll add that).
FAQs and pointers be darned; there is only one way to developerhood and that is through the school of hard knocks. - Learn to use CVS (which, of course, entails SSH and such). - Use Googol (a lot), or risk proposing that which has already been decided, researched, or discussed ad naseum. - Submit a patch. Find out that it was the wrong diff format or keyed-off of an older, non-current version of the file. Then find-out that your editor's tabbing and spacing confounds somebody's life, somewhere. Oh, did you forget to run the regression tests? Did your tests run fine, but you didn't run them in debug mode? Perhaps your Windows machine skips the test for the library you modified. Break working code and suffer public flogging. - Read every PEP and make sure your patch style has no deviations (unless, of course, your C and Python coding style already matched the PEPs). - BTW, did you submit unittests and docs with your patch? Did you make appropriate adjustments to the makefiles, and every other reference to you work? And appropriate announcements in Misc/NEWS? - Surely, you've learned TeX and its many Python specific macros (forward slash or backslash, verbatim or code?) How many characters were on your longest line (72, 78, hopefully, not more). - When learning a guitar, it helps to develop calluses on the fingers. Write a PEP is the fastest way to develop the calluses; contradicting Guido is the second fastest way; submitting a great idea is third fastest (bad ideas either get ignored or are slammed so quickly that the scar tissue doesn't have time to develop). - Experience the politics of bug resolution. If a developer proposed it, then it should not be dismissed lightly. If someone had a grandiose scheme in mind when they submitted the report, be prepared for wrath when you apply a simple solution. Realize that, in some cases, someone, somewhere is relying on the undocumented buggy behavior and your fixing it is breaking their code. - And, my all time favorite, do everything right (formatting, procedure, profiling, testing, etc) and watch the Timbot come along five minutes later and improve your code making it faster, clearer, more conformant, more elegant, and also gel neatly with the vaguaries of memory allocation, cache performance, and compilers you've never heard of. Raymond Hettinger Oh, and did I mention that native speakers of ASCII will never be able to master Unicode like a native?
[Raymond Hettinger] <a whole lot of funny stuff> Kudos to Raymond on this email. Great stuff. I know I have had my growing pains with learning how to do everything correctly, so I really appreciate his points. -Brett
Michael> Couldn't Zack's comment be added to the directions found at Michael> https://sourceforge.net/tracker/?func=add&group_id=5470&atid=305470 Michael> so that anyone submitting a patch would see how to do it. On that page there's a link entitled "See our hints on how to create a patch." This links to http://www.python.org/patches/ which has, I think, the required details. -- Skip Montanaro skip@pobox.com consulting: http://manatee.mojam.com/~skip/resume.html
Michael> Couldn't Zack's comment be added to the directions found at Michael> https://sourceforge.net/tracker/?func=add&group_id=5470&atid=305470 Michael> so that anyone submitting a patch would see how to do it.
On that page there's a link entitled "See our hints on how to create a patch." This links to
http://www.python.org/patches/
which has, I think, the required details.
I added that link a few minutes ago. :-) --Guido van Rossum (home page: http://www.python.org/~guido/)
participants (8)
-
Aahz -
Brett Cannon -
Guido van Rossum -
Jack Jansen -
Jack Jansen -
Michael Chermside -
Raymond Hettinger -
Skip Montanaro