Re: [exim-dev] Development blockage...

> You're kidding, right? A project that no longer develops can, for all
> intents and purposes, be dropped because it will not be able to adapt to
> an ever-changing world.

Not immediatly, but within 5-10 years, yes.

> Look at domainkeys, for example. As far as I can tell, it's still not
> easy to do with exim, so when smaller shops come to a decision to
> implement DK they might have to use a different MTA.

Perhaps, yes. If I was interested in using DKIM, I would look at it,
but right now I am not. And it sounds like most developers here think
so, too. You are free to present well commented patches to change that
(see below).

> And if *nobody* is willing to help triage bugzilla, then you might as
> well admit to the fact that nobody is interested in exim enough any more
> to care about adapting it to a changing world, so when new requirements
> come up you would move to a new MTA.

The use of Exim might go back to people who are not afraid of C, being
able to hack Exim for their needs on their own or with a little help from
other people doing the same. What's missing there are big changes: Exim
5 with 20-30% code rewritten (just a guess), but that is not required
real soon, so I am not worried right now. It does not take bugzilla
or git or whatever else, it takes someone adopting Exim. Until then, I
suggest not to pretend anybody does and cut back things to what's there:
People making patches for their installations, and sharing them.

Let's try to find a way for dealing with that is all I ask for. If nobody
cares about bugzilla, then we don't need it, but people do care about
serious bug reports. Would a mailing list solve the conflict? A few
people have CVS access, but most are afraid of changing Exim on their own.
In the past, Philips reviewed all patches. How can we fulfill the need
of reviewing changes? Exim-dev is there, perhaps it is time to use it
for presenting patches, describing them, and if there is a consensus
they are good, anybody with CVS access may commit them without fear.

I read something about a patch for dynamic lookup methods. We might
start with that. How about sending a description of the change (text,
not code) plus an URL for the diffs to exim-dev? Most people here have
little spare time and would not dig into endless uncommented diffs,
but the interest may rise upon a documentation that sounds promising.
I promise I'll review it at least based on the documentation, because
resolving the dependency issue would be useful to me.

Then there is the question of new releases. Who can (technically)
make new releases?

Michael