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 -- ## List details at https://lists.exim.org/mailman/listinfo/exim-dev Exim details at http://www.exim.org/ ##
