[150874] trunk/dports/lang/python32

[Jeremy Huddleston Sequoia]

FWIW, I prefer 'git format-patch' output for patches.  If I actually had to rename patches per file, maintaining llvm would be a nightmare. =/


> On Aug 4, 2016, at 05:35, Clemens Lang <cal at macports.org> wrote:
> 
> 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
> _______________________________________________
> macports-dev mailing list
> macports-dev at lists.macosforge.org
> https://lists.macosforge.org/mailman/listinfo/macports-dev

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4465 bytes
Desc: not available
URL: <https://lists.macosforge.org/pipermail/macports-dev/attachments/20160806/ebeaa5d2/attachment.p7s>