RE: 1.2.0 betas

> -----Original Message-----
> From: opendkim-dev-bounce_at_lists.opendkim.org [mailto:opendkim-dev-
> bounce_at_lists.opendkim.org] On Behalf Of Daniel Black
> Sent: Wednesday, November 11, 2009 5:32 AM
> To: opendkim-dev_at_lists.opendkim.org
> Subject: 1.2.0 betas
>
> > Modifications to libopendkim to support this were minimal, but
> opendkim
> > took quite a beating. Basically I have to activate
> > _FFR_MULTIPLE_SIGNATURES, which is probably not a bad idea anyway,
> just to
> > get the baseline code to a place where _FFR_RESIGN can go in nicely.
>
> ok by me.
>
> anything else we want to move from _FFR to FEATURE status?
>
> thinking:
> stats
> identityheader
> selectorheader
> reportintervals
> sendermacro

In the past I've activated FFRs only after they're known to have been in use someplace for a while. Although I developed and tested these, I don't know that they're getting real-world use anyplace enough that I'd feel confident turning them on yet.

Stats in particular is an interesting one. I took a crack at getting it collecting and reporting data I thought were useful, but never heard back from anyone else about whether or not it was right, or whether other data or data formats would be better. I know you had some thoughts in this area, for example. I think I might ask the working group what information they'd like to have gathered and then re-do the stats code to do that, and let it run for a while. This is also what I'd mentioned about maybe doing anonymous reporting as a compile-time option.

> Stuff that's been mentioned and is it planned for 1.2.0?
>
> - statistics gathering

See above. :-)

> - doxygen doco

I have that on a branch but haven't gone too far with it yet. _FFR_RESIGN took way more time than I expected. It'll probably slip out of 1.2.0.

> - milter test framework

I think I want to do both unit tests for opendkim and then integration tests as you suggested. Probably won't be done soon, so it'll be after 1.2.0.

> - libopendkim tests to a subdirectory

Still planned for 1.2.0. I think I'm going to just do a mass "cvs remove" and "cvs add" shortly before the release; there's not much in the way of important CVS history that will be hidden by doing it that way.

> - policy API framework (guessing this is going to wait)

Yeah, that's longer-term. And we hadn't decided on LUA yet as I recall.

> Ok. I'll set some branches up for my goals:
> [...]

Great! Make sure to note them in the BRANCHES file at the root.
Received on Wed Nov 11 2009 - 16:55:53 PST