[150874] trunk/dports/lang/python32

[Clemens Lang]

FWIW, I agree with Lawrence here. I think we should improve our patch
naming, especially since it doesn't really matter *where* a patch comes
from, either. Why do we really need to know whether a patch-*.diff file
comes from MacPorts when compared to a different patch? We should be
judging patches by their content, not their origin.

What I've seen in other systems and would also recommend as a guideline
for patches in MacPorts:
 - Write a commit message into the patch file. Patch headers can include
   arbitrary text, so type a message explaining what the patch does and
   why it is needed. Add references to any upstream tickets (I've
   started doing this for my ports according to OpenEmbedded's
   Upstream-Status tag [1]).
 - Use the summary line of the commit message as patch name, like git
   format-patch does it.

I have in the past also ignored our patch naming guidelines when I
thought it made sense; for example, I generally backport patches from
upstream git repositories using <commithash>.patch, because that's what
GitHub generates.

[1] http://www.openembedded.org/wiki/Commit_Patch_Message_Guidelines#Patch_Header_Recommendations

-- 
Clemens
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: not available
URL: <https://lists.macosforge.org/pipermail/macports-dev/attachments/20160804/cb055aa5/attachment.sig>