Ken Jones wrote:
> I'd like to keep it in the vpopmail project. The daemon could be part of
> the regular code and the php client module could be part of contrib?
> I really like the idea of a wiki, too bad we don't have one for vpopmail.
My only problem with that solution is that I wouldn't want to see the
daemon and related php client so closely tied to vpopmail that releases
have to be based on releases of vpopmail itself.
I think if it does stay in the vpopmail area of sourceforge (or else
where) that it should be it's own separate downloadable package and not
something that you have to download vpopmail to get.
Yes, that's what I mean when I told Ken that they must be very serious about
it. We had similar siutaiton when we revived pgaccess (www.pgaccess.org) 3
years ago (a Tcl/Tk GUI for PostgreSQL). The PostgreSQL team wanted it
closer and we wanted it not so close. At the end they must focus on
PostgreSQL and we - on pgaccess. If the main project gets into a difficult
time (change of maintainers, etc.) - and if the sub-project is too close -
it can suffer. At the end - the spirit of qmail is modularity - why
shouldn't we continue it? I am not against - I just think we should be aware
of the dangers of the thing getting stuck and killing a lot of investment in
infrastructure and code that uses it.