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>
>>
