Quick scan of gitorious changes

From: Murray S. Kucherawy <msk_at_cloudmark.com>
Date: Tue, 20 Oct 2009 12:23:18 -0700

Hey Daniel, here are some comments after a quick scan of your changes to the code line as visible through the Gitorious UI. There are a lot of changes in there so I may have missed how some of them tie together, so feel free to point out the bits I've missed. I've also skipped over a few of the configure.ac ones until I catch up to what you've been doing.

http://gitorious.org/opendkim/opendkim/commit/4a4cd690df04d33cd842ff05b4457dda0c994389

- Hard to tell what's in here that's different from OpenDKIM as there was no prior commit as a baseline

- You deleted "_FFR_PARSE_TIME" from util.c; was it removed throughout?

http://gitorious.org/opendkim/opendkim/commit/660e0bd48120fea2c7f4fa9591fa58b2253ed8fb

- I like this a lot; I'd like to use it for future releases

http://gitorious.org/opendkim/opendkim/commit/d7b9ca346430629b54faff8278bd0e6d73ab29e3

- Ditto, this is a good idea

http://gitorious.org/opendkim/opendkim/commit/6001d072d12b87ee948a4762e1732b81ac73de66

- I'm not clear on why this is needed; don't opendkim_CPPFLAGS and opendkim_LDFLAGS refer to ../libopendkim, making this unnecessary?

http://gitorious.org/opendkim/opendkim/commit/43e13d1b3623923d95d48efb7c2b1c1c35ad45d4

- All four of the FFRs you modified here actually do enable or alter code inside libopendkim, so I believe the FEATURES file is correct as-is.

http://gitorious.org/opendkim/opendkim/commit/a8a376ed12106ecc71bea278a83cad215fbb91c4

- The build-config.h.in contents are automatically produced by autotools so we don't track them in our repository.

http://gitorious.org/opendkim/opendkim/commit/f7dab7df233668a7c1f1cc9a964c415df4fa84a9

- Why was this removed? There are some consumers of this package that care only about the library and don't need the filter. We shouldn't force them to compile it or to install libmilter.

http://gitorious.org/opendkim/opendkim/commit/6393565f96c9d44ba16fcbe3780329f253097364

- Is this true if the libraries are all static instead of shared? In that case, the binary won't know how to resolve tre_regcomp(), for example (unless it happens to be in libc or something).
Received on Tue Oct 20 2009 - 19:23:39 PST