I'd like to formally request that these new style guideline be removed from port lint -- there's nothing wrong with the port. This kind of style pedantry wastes everyone's time. It doesn't matter. The last thing I need is an e-mail about it. I didn't place newline between the $Id: $ tag and the PortSystem line: # $Id: Portfile 35353 2008-03-25 18:13:44Z landonf@macports.org $ PortSystem 1.0 I named my patch file 'patch-tinyca2'. -landonf Begin forwarded message:
From: noreply@macports.org Date: March 25, 2008 11:13:49 AM PDT To: landonf@macports.org Subject: [35353] tinyca2 Lint Report
Portfile: tinyca2
Warning: Line 2 should be a newline (after RCS tag) Warning: Patchfile patch-tinyca2 does not follow the source patch naming policy "patch-*.diff"
How long does it take to fix it? One minute. It took longer to write this email then to commit those changes :) Blair Landon Fuller wrote:
I'd like to formally request that these new style guideline be removed from port lint -- there's nothing wrong with the port. This kind of style pedantry wastes everyone's time. It doesn't matter. The last thing I need is an e-mail about it.
I didn't place newline between the $Id: $ tag and the PortSystem line:
# $Id: Portfile 35353 2008-03-25 18:13:44Z landonf@macports.org <mailto:landonf@macports.org> $ PortSystem 1.0
I named my patch file 'patch-tinyca2'.
-landonf
Begin forwarded message:
*From: *noreply@macports.org <mailto:noreply@macports.org> *Date: *March 25, 2008 11:13:49 AM PDT *To: *landonf@macports.org <mailto:landonf@macports.org> *Subject: **[35353] tinyca2 Lint Report*
Portfile: tinyca2
Warning: Line 2 should be a newline (after RCS tag) Warning: Patchfile patch-tinyca2 does not follow the source patch naming policy "patch-*.diff"
Landon Fuller wrote:
On Mar 25, 2008, at 11:25 AM, Blair Zajac wrote:
How long does it take to fix it? One minute.
It's not broken. It's just like a spell checker that gets annoyed when you type "colour" instead of "color".
Teams have style guides for everything, such as no space before a ( for the Subversion source code, everybody plays along with it. Just go along with it. I found a bunch of stuff in my port files and cleaned it up. I don't have an issue with it. There's more important stuff to discuss about. Blair
On Mar 25, 2008, at 11:31 AM, Blair Zajac wrote:
Landon Fuller wrote:
On Mar 25, 2008, at 11:25 AM, Blair Zajac wrote:
How long does it take to fix it? One minute. It's not broken. It's just like a spell checker that gets annoyed when you type "colour" instead of "color".
Teams have style guides for everything, such as no space before a ( for the Subversion source code, everybody plays along with it.
The original style guidelines only tried to enforce things that mattered.
Just go along with it. I found a bunch of stuff in my port files and cleaned it up. I don't have an issue with it. There's more important stuff to discuss about.
So why do we have a machine auto-emailing humans about stuff that doesn't matter that much? -landonf
Landon Fuller wrote:
On Mar 25, 2008, at 11:31 AM, Blair Zajac wrote:
Landon Fuller wrote:
On Mar 25, 2008, at 11:25 AM, Blair Zajac wrote:
How long does it take to fix it? One minute. It's not broken. It's just like a spell checker that gets annoyed when you type "colour" instead of "color".
Teams have style guides for everything, such as no space before a ( for the Subversion source code, everybody plays along with it.
The original style guidelines only tried to enforce things that mattered.
Just go along with it. I found a bunch of stuff in my port files and cleaned it up. I don't have an issue with it. There's more important stuff to discuss about.
So why do we have a machine auto-emailing humans about stuff that doesn't matter that much?
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. Blair
On Mar 25, 2008, at 11:40 AM, Blair Zajac wrote:
Landon Fuller wrote:
On Mar 25, 2008, at 11:31 AM, Blair Zajac wrote:
Landon Fuller wrote:
On Mar 25, 2008, at 11:25 AM, Blair Zajac wrote:
How long does it take to fix it? One minute. It's not broken. It's just like a spell checker that gets annoyed when you type "colour" instead of "color".
Teams have style guides for everything, such as no space before a ( for the Subversion source code, everybody plays along with it. The original style guidelines only tried to enforce things that mattered. Just go along with it. I found a bunch of stuff in my port files and cleaned it up. I don't have an issue with it. There's more important stuff to discuss about. So why do we have a machine auto-emailing humans about stuff that doesn't matter that much?
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. -landonf
On Tue, Mar 25, 2008 at 11:45:12AM -0700, Landon Fuller wrote:
On Mar 25, 2008, at 11:40 AM, Blair Zajac wrote:
Landon Fuller wrote:
On Mar 25, 2008, at 11:31 AM, Blair Zajac wrote:
Landon Fuller wrote:
On Mar 25, 2008, at 11:25 AM, Blair Zajac wrote:
How long does it take to fix it? One minute. It's not broken. It's just like a spell checker that gets annoyed when you type "colour" instead of "color".
Teams have style guides for everything, such as no space before a ( for the Subversion source code, everybody plays along with it. The original style guidelines only tried to enforce things that mattered. Just go along with it. I found a bunch of stuff in my port files and cleaned it up. I don't have an issue with it. There's more important stuff to discuss about. So why do we have a machine auto-emailing humans about stuff that doesn't matter that much?
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>? -eric
There's now a ticket with a patch to reduce 'port lint' pedantry: http://trac.macosforge.org/projects/macports/ticket/14799 -eric
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. Florian -- Florian Ebeling florian.ebeling@gmail.com
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.
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.
Agreed, that's maybe a good idea. It seems to be hard to eliminate problems which lint warns about beforehand. To give you just one example, the last 2 commits on "my" port libsvm were done by you, and I got a lint warning each time, for an empty line containing a space. -- Florian Ebeling florian.ebeling@gmail.com
On Mar 26, 2008, at 05:42, Florian Ebeling wrote:
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.
Agreed, that's maybe a good idea. It seems to be hard to eliminate problems which lint warns about beforehand. To give you just one example, the last 2 commits on "my" port libsvm were done by you, and I got a lint warning each time, for an empty line containing a space.
Empty lines containing a space should not be reported as erroneous by port lint. port lint had a bug. It was fixed in trunk but that fix has not yet made it to a released version of MacPorts. http://trac.macosforge.org/projects/macports/ticket/14165
Empty lines containing a space should not be reported as erroneous by port lint. port lint had a bug. It was fixed in trunk but that fix has not yet made it to a released version of MacPorts.
Ok, fair enough. Btw, is there a way to run port lint locally? It's not mentioned in the macports guide, IIRC. -- Florian Ebeling florian.ebeling@gmail.com
On Mar 26, 2008, at 12:13 AM, Ryan Schmidt wrote:
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".
The original documentation (which I wrote) was originally consistent with the FreeBSD patch specification: http://www.freebsd.org/doc/en_US.ISO8859-1/books/porters-handbook/slow-patch... We then adopted the semantic of patch-foobar.diff, where 'foobar' was a feature that covered many files -- this was due to the headache of patch-per-file for a sizable set of diffs. I don't actually think it matters what name you use, as long as it makes sense.
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.
I don't want to get e-mailed when I name a patch that makes *your* editor unhappy when you double-click a file. The e-mail should be saved for something that's actually an error.
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.
My original newline complaint was: Warning: Line 2 should be a newline (after RCS tag) # $Id: Portfile 35353 2008-03-25 18:13:44Z landonf@macports.org $ PortSystem 1.0 Why does that matter? These "your contribution is in error!" mails are soul draining. It makes one feel as if you've stumbled into the Department of Motor Vehicles and forgot registration form B.5. -landonf
On Mar 26, 2008, at 8:53 AM, Landon Fuller wrote:
Why does that matter? These "your contribution is in error!" mails are soul draining. It makes one feel as if you've stumbled into the Department of Motor Vehicles and forgot registration form B.5.
I agree fully with Landon. The automated lint on submit should be limited, if even allowed, to severe errors that will cause the port to be unusable. We have enough of a hard time getting people to keep their ports up to date, without adding layers of unneeded complexity. I don't mind if somebody wants to be able to run a lint that shows tweaky and silly warnings, but that should be their choice, on their system. We should either: - Disable the automated link-on-submit - Or cause it to show severe errors only James
Florian Ebeling wrote:
Empty lines containing a space should not be reported as erroneous by port lint. port lint had a bug. It was fixed in trunk but that fix has not yet made it to a released version of MacPorts.
Ok, fair enough. Btw, is there a way to run port lint locally? It's not mentioned in the macports guide, IIRC.
$ port lint PORT_NAME Blair -- Blair Zajac, Ph.D. <blair@orcaware.com> http://www.orcaware.com/svn/
participants (6)
-
Blair Zajac
-
Eric Hall
-
Florian Ebeling
-
James Berry
-
Landon Fuller
-
Ryan Schmidt