[150874] trunk/dports/lang/python32

[Mihai Moldovan]

On 01.08.2016 08:39 PM, Lawrence Velázquez wrote:
> Not to pick on you, Mihai, but have we ever considered getting rid of (or at 
> least revising) the guideline that implies that these new, sprawling, 
> indecipherable patch names are somehow more "correct" than the old ones? I 
> have never understood the point of including the name(s) of the modified 
> file(s) in the name of the patch itself, when this information is *already 
> inside the patch*.

There are multiple points to this guideline.

Starting with "patch-" and ending in ".diff" probably is a good one, because we
can easily distinguish MP patch files from other contrib files. Just ending in
".patch" might also be possible, but an ending is less obvious than a fixed
start. I kinda like that one.

Then, the identifier. As already pointed out by others, there's no fixed
guideline as to what this should be comprised of, although the example seems to
mandate including the file name.

> And these aren't even the worst: Many patches are just named after the files 
> they modify, with no information about their purpose. I don't think I should 
> have to resort to version control to get the first inkling of a patch's 
> purpose.

Using the file name/path alone as the identifier is something I am (and you are)
personally strongly against, because I *still* don't know what it's good for
just by looking at it.

Instead, I like to have a (short) description included in the identifier. The
other side of the coin, of course, is that this inevitably leads to "sprawling",
complex file names. Still, I think that's better than not knowing what a patch
is for.

Including both file names and description is probably my own quirk stemming from
my convention of naming git commits/writing up the first line of a git commit:

filenames (as compact as possible): description.

Most of the time, this can be written quite compactly, although sometimes it
does tend to blow up. Because I try to avoid special characters in file names,
the "blowing up" situation is even worse there.

And yet that helps me determining the patch order or rather dependencies within
patches. Yes, it's redundant information, but more concise than opening a patch
file and finding out what real files that patch changes or grepping for headers.



Mihai

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 884 bytes
Desc: OpenPGP digital signature
URL: <https://lists.macosforge.org/pipermail/macports-dev/attachments/20160802/0c411992/attachment.sig>