[snip] Rick Macdougall: 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. Hi, 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. [snip] 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.