On 2013-04-01 at 14:05 -0700, Todd Lyons wrote:
> I asked (I think it was) Phil about it a long while back, and he said
> (my recollection and paraphasing) "if you edit someone else's file,
> follow whatever convention they used, but if you own/create the file,
> use whatever works best for you." It's trivial to change if that
> position is not popular.
Sounds about right; ideally, the style used by Phil Hazel, but so many
files have differing styles that I'm not going to insist for new files,
it would be hypocritical.
But "ideally" is really something to aim for, which I probably failed to
communicate: mea culpa, sorry.
(I _Really_ like "go fmt", even if some of its decisions irritate)
> > switch(libdbm_status) - consider a tabled-based coding.
>
> Ok, I liked the switch, but I'll work on a table.
For clarity: why consider a table-based config? Is this "have you
considered ..", or "I'd have done it this way, but it doesn't matter" or
is this "I believe there are benefits to using a table-based config so
we really should"? And if the last, why?
Code-reviews are handy for catching bugs, but I get uncomfortable when I
see folks changing their whole coding approach based on a "consider" and
want to make sure that something intended as a glib comment isn't being
misinterpreted as a mandate to change.
> Honestly the test suite has been somewhat of an enigma for me. The
> SPF and DKIM libraries require live lookups, whereas I could stuff dns
> values into the DMARC library. Phil advised that live lookups were
> better so long as we controlled the data it looked up, so that's what
> I tried to use (first tried against my own dns server). But when it
> came right down to it, the exact same commands run under the test
> suite performed differently WRT dkim/dmarc from when I ran the same
> command manually. I never did zero in on the problem, so I pushed it
> back to "look at it later" status. If no test suite is a show stopper
> for an experimental feature, I'll have to delve more deeply into the
> behavior I was seeing.
Test-suite overrides a lot of DNS initialisation; this makes it awkward
to test real-world interactions.
Normally, I'd say that "no test suite is an argument for keeping
something in experimental rather than main" and we wouldn't press hard
for a contribution to have accompanying tests, but if code is going to
be extensively changing existing files, it becomes more important to be
able test the impact of the changes.
-Phil
