Re: v2.9.0 release planning

From: Scott Kitterman <ietf-dkim_at_kitterman.com>
Date: Wed, 10 Apr 2013 23:39:35 -0400

On Tuesday, April 09, 2013 11:51:49 PM Murray S. Kucherawy wrote:
> I'm starting to think about what to include in a 2.9.0 release for the
> summer. There are about five open feature requests that seem like likely
> candidates, but none of them involve a huge amount of work, so we can
> think bigger. Does anyone have an existing or new feature request they'd
> like to have considered?
>
> Are there any FFRs that we might consider for full activation, because
> they've seen use in production and appear to be useful? Here's the
> current list:
>
> _FFR_ADSP_LISTS
> _FFR_ATPS
> _FFR_DEFAULT_SENDER
> _FFR_DIFFHEADERS
> _FFR_DKIM_REPUTATION
> _FFR_IDENTITY_HEADER
> _FFR_LDAP_CACHING
> _FFR_POSTGRESQL_RECONNECT_HACK
> _FFR_RATE_LIMIT
> _FFR_RBL
> _FFR_REDIRECT
> _FFR_REPLACE_RULES
> _FFR_REPRRD
> _FFR_REPUTATION
> _FFR_RESIGN
> _FFR_SENDER_MACRO
> _FFR_SOCKETDB
> _FFR_STATS
> _FFR_STATSEXT
> _FFR_VBR

For the Debian/Ubuntu packages, here are the options I'm using:

                --disable-live-testing \
                --enable-vbr \
                --enable-rbl \
                --enable-atps \
                --enable-stats \
                --enable-replace_rules \
                --enable-query_cache \
                --with-libmemcached \
                --with-unbound \
                --with-openldap \
                --with-db \
                --with-libxml2 \
                --with-odbx \
                --with-sql-backend \
                --with-sasl \
                --with-test-socket=inet:8891_at_localhost \
                --with-lua

Some things I'd like to see:

More comprehensive non-live testing. On the distro builders, we don't have
internet access, so I have to disable live testing and it would be nice to
have the non-live tests be fully comprehensive. For Debian, opendkim is built
for 13 release architectures and 3 unofficial ports. The current test suite (as
msk already knows, because I've bugged him about issues) has been very helpful
to identify porting issues and it would be good to be more comprehensive so we
can be more confident that's it's broadly functional.

Allow more run time decision making about what features are enabled. Here are
the dependencies that opendkim currently pulls in on Debian/Ubuntu due to the
enabled options:

libdb5.1
libldap-2.4-2
liblua5.1-0
libmemcached10
libmemcachedutil2
libopendbx1
librbl1
libunbound2
libvbr2

Not everyone will want all these things, but since there's one opendkim
package built for the distro, I made the decision to enable all the options
that seemed reasonable to make the package as broadly useful as possible. It
would be nice is opendkim could be made more modular so that the (for example)
VBR code is only enabled when libvbr is installed. I'm not sure what the best
design would be, but the goal would be to allow one build to be used in
multiple different configurations without recompiling. For source based
distros/ports this isn't a major issue, but for binary distros it is.

Scott K

P.S. Now that we've been through a development cycle with running the tests
on all builds, I hope I'll have lest complaining to contribute to the next
one.
Received on Thu Apr 11 2013 - 03:39:51 PST