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

> The migration is easy enough -- we have a git tree which is following
> the CVS tree automatically; all we have to do is stop committing to CVS
> and start committing to the git version.

At the current rate of acticity, why bother changing? If you still do,
please write a step by step documentation that explains how to checkout
the sources and commit changes for this particular installation. Keep it
easy for occasional developers to commit changes.

To me, Exim is now at the point of many successful open source projects:
It is mature and widespread, there are very few bugs, and it attracts
lots of people who cry that nobody fulfills their wishes for free, be it
reading the manual or implementing new features. Philip did both, and
with memorable patience. It was to be expected that nobody else would.

A central place to report bugs is good, but bugzilla rises the expectation
somebody will care, and the false impression Exim is full of bugs, only
because there are many open reports, few, if any, of them being serious.
How about dropping bugzilla and the wishlist, too?

If there was exim-bugs, restricted to true bug reports, I would join
the list and if a bug concerned me, I would certainly look for a fix.
I suppose most postmasters on this list would.

Face it: Besides the majority of work done by Philip, all contributions
were made by people who needed them. That is not going to change,
and the best that can be done is supporting that circle. What's the
policy on comitting patches and who allows to commit them? Who makes
new releases, so CVS never moves too far away?

Michael