On Mar 25, 2008, at 15:36, Florian Ebeling wrote:
I'm guessing by the few emails I've seen taking issue with the style emails that most people don't mind and that that the people that wrote the tool felt that style does matter.
I'm in that camp. I like seeing all the ports having the same style.
OK. If that's the prevailing opinion I'll just /dev/null the lint warnings, hopefully not miss anything truly important, and get on with work.
Is it? I don't like the 'port lint' stuff that complains about whitespace - its invisible to humans and to port (so far as I know), why do we bother people about it? I also don't like having patchfiles ending in '.diff', used to be they matched FreeBSD's style (IIRC, and that was a purposeful decision). If somebody has a hair about their editor "properly" displaying patches, why not teach the editor to match on 'patch-' for highlighting/<whatevering>?
The pedantery of port lint is particularly embarassing for occasional maintainers like me who don't have commit bit. The thing is I can't really ask the list to "please delete the space at the and of line 14", as lint suggests and expect that people still take me serious. Effectively, I can't really do anything about this stream of little nagging notes, and that's not good.
Maintainers who don't have commit access: I would expect everyone who is a maintainer but not a committer to have a commit-buddy whom they email to commit such things for them. If you don't have one, it would be advantageous to find one. For example, who has committed the patches you supplied in your last tickets? Ask them. Patchfile naming: The old guide was contradictory, and in one place, recommended the naming scheme "patch-*" while in another place it recommended "patch-*.diff". The new guide is now consistent in recommending "patch-*.diff". As I have explained over and over on this list, I prefer this because my editor can then syntax-highlight diff files like diff files, instead of like whatever the underlying file type is, which would be an error, because, e.g., the difference of two C files IS NOT a C file; it is a difference file and should be treated as such. Mac OS X cannot assign applications based on file prefixes. It can only assign applications based on file extensions. Therefore diff files must have a unique extension, as should all other types of files. Trailing whitespace: trailing whitespace after a backslash causes an error (the line is not continued as expected). Such whitespace must not exist. I'm not sure if there are other trailing whitespace issues that were being caught by this check. If not, the check could be reduced to catching trailing whitespace following a backslash.