-------- Original-Nachricht -------- > Datum: Tue, 27 Nov 2007 03:09:04 -0000 > Von: "Brian Sullivan" <[EMAIL PROTECTED]> > An: [email protected] > Betreff: Re: [dspam-users] Dspam Fork?
> Paul Cockings wrote: > > > My preference would be if the dspam community as a whole could move to a > > new project, but I'm not sure if anyone will come! > > Maybe thats what a dspam fork would be... a new project, or projects. The > biggest problem with dspam is that it tries to do too much and fit too > many > moulds right out of the box. No baysian algorithm specialist is going to > be > a webapp specialist or postgres specialist. Find a specialist in every > dspam > area, and you've got someone who can't document the thing etc etc... > Johnathan's achievements in this regard (multi discipline expertise) are > phenominal but it leaves a vast project that nobody can easily step into. > Sorry but this is so wrong in many aspects. Johnathan has not wrote DSPAM to be complicated but to do a job. He has not modeled DSPAM for baysian algorithm specialists or database specialists or web application developers or or or but for filtering spam and ham for users. And to be honest: he has done a very decent job. > > A new project would need to maintain the bulk of the knowledgeable > people > > found here, a return of Jonathan in some way if he is able, and a > > structured way that we can all commit back those patches without turning > > dspam into a black hole of focused smaller projects, that in time will > > become unmaintained. > > dspam would be easier to maintain if it was split into three projects, the > daemon, LDA and the web admin. The storage driver support should be > reduced > down to one, mysql and drop hash databases etc which are only a cop out > for > people who couldn't be bothered reading how to setup mysql (IMHO) and > which > are the source of a lot of open bugs. In fact, there's little advantage to > dspam being an lda and that portion could be dropped and just ride off the > successes that are maildrop procmail etc etc. > > With that kind of a split, you can get focused groups to easily maintain > their own portion without getting into knots to bend over backwards to > suit > people, and it leaves the integration possibilities the same and makes the > documentation project easier. > Have you ever looked at the code of DSPAM? It is very well structured and not that bad as you state. It is pretty much already split in the areas you mention. I am totally against dropping the other storage engines. And the hash driver has a reason it is there: You can not save fast enough SBPH into any other storage backend then into hash. If you ever looked into CRM114 and SBPH or Markovian then you would know why the hash driver is there in DSPAM. And since when is DSPAM a LDA? It only speaks SMTP or LMTP (DLMTP). It does not try to replace procmail or maildrop. It even uses the two but no where does it try to replace them. > > I see a need for a fork, but have no experience of a project lead in > this > > way - the setup on sf.net is the easy bit, but will anyone else be > > interested if I did it? > > Project leads are easy to get, what you need are developers who can read > and > understand code and are willing to patch, test and release. > No! That's only the half of the game. You need a goal as well. A global picture, a target or something like that. You need someone to draw the target where DSPAM is going. Someone capable to push DSPAM to evolve and not just a project leader, a release manager and a bunch of developers fixing bugs and maintaining documentation. > Brian. > Steve -- GMX FreeMail: 1 GB Postfach, 5 E-Mail-Adressen, 10 Free SMS. Alle Infos und kostenlose Anmeldung: http://www.gmx.net/de/go/freemail
