On May 9, 2010, at 11:42 PM, Robert Spier wrote: > Assuming > http://github.com/msimerson/qpsmtpd/commit/6948c27205ebdec045604bd8d6bf6a3a04c35a8a > is the output of this experiment...
Tis true. > If we were to just fix the "big issues", I think that would help most > places without causing the huge churn, and hard to review change. > > By "big issues" I mean: > tab vs spaces > trailing whitespace > > I was going to include 4 vs 2 in there, but I'm not sure even that > makes a huge difference. git config --global apply.whitespace nowarn Would that prevent any undue hardship, on the part of people with outstanding patches? > If we're going to do this, we need to get all outstanding patches > merged and just bite the bullet. It'll only suck during the > transition. (And for anyone backporting patches.) Is there a list of outstanding patches somewhere? I care enough to do the legwork. > But with the exception of some annoying tab/space stuff, what's the > big win from doing this? It sets the expectation for new contributors that there is a code standard and it should be adhered to when making submissions. It will also let me install a git pre-commit hook that automatically runs perltidy on the files I'm changing. If I do that now, it will almost certainly make all the patches I submit much larger. I'm of the opinion that whitespace changes such as changing from 2 to 4 spaces should be done en masse with no other changes. If all the files have been tidied, I will create that pre-commit hook, and I'll update docs/development accordingly, making it ultimately easier on everyone to have consistently formatted files. Matt > Matt Simerson wrote: >> >> There's a nifty .perltidyrc file in the git repo. >> >> There's also a lot of code that uses tab indents, 2 space indents, and 4 >> space indents. And of course, code that uses a mixture of the three, with >> local variations thrown in for good measure. >> >> I figure that the least invasive time to do a wholesale perltidy is right >> after a release, when most of the outstanding patches and forks that will >> get merged in already have been. And a whitespace change should not be >> combined with other changes. So I did this on my fork: >> >> find . -name '*.pm' -exec perltidy -b {} \; >> find plugins -type f -exec perltidy -b {} \; >> perltidy -b qpsmtpd* >> find . -name '*.bak' -delete >> >> And then manually perused through the changes, found the instances where >> perltidy did not do The Right Thing[TM] (like altering the contents of a >> here doc), ran the test suite, and submitted the change for inclusion. Ask >> asked me to post the change to this list for comment. >> >> Will this change disrupt anyone significantly? Is there anything I can do >> that makes this change less disruptive (ie, avoid files in list .... ). >> >> Thanks, >> Matt >> >> Begin forwarded message: >> >>> From: mailer-dae...@lists-nntp.develooper.com >>> Date: May 3, 2010 11:32:14 AM PDT >>> To: m...@tnpi.net >>> >>> Hi. This is the qmail-send program at lists-nntp.develooper.com. >>> I'm afraid I wasn't able to deliver your message to the following addresses. >>> This is a permanent error; I've given up. Sorry it didn't work out. >>> >>> <perlmail-qpsm...@onion.perl.org>: >>> ezmlm-reject: fatal: Sorry, I don't accept messages larger than 400000 >>> bytes (#5.2.3) >>> >>> --- Below this line is a copy of the message. >> >> <snip> >>