[Pkg-dspam-misc] Bug#577661: Status of DSPAM in Debian

[Stevan Bajić]

On Mon, 28 Mar 2011 08:58:47 +0200
Julien Valroff <julien at debian.org> wrote:

> Hi Stevan,
> 
> Good to hear from you!
> 
Hello Julien :)


> Le lundi 28 mars 2011 à 01:31:34 (+0200 CEST), Stevan Bajić a écrit :
> > On Sat, 26 Mar 2011 22:20:48 +0100
> > Ana Guerrero <ana at debian.org> wrote:
> > 
> > > On Sat, Mar 26, 2011 at 10:16:00PM +0100, Julien Valroff wrote:
> > > > 
> > > > I plan to upload current git snapshot to experimental very soon - not
> > > > everything was tested as much as I would have expected, and I think some
> > > > documentation would need to be checked/rephrased/updated but the package has
> > > > been in use on several production servers for some time now, which makes me
> > > > confident for the future.
> > > >
> > > 
> > > Experimental is experimental after all :-)
> > >
> > Maybe the Debian package is experimental but the product it self is not
> > experimental. 
> 
> Ana and I were refering to the Debian package - you know I am using several
> instances of DSPAM in production, and I am totally confident with the
> product itself.
> 
I redirect everyone I know using Debian or Ubuntu to your repository and so far all of them have a running DSPAM without issues. The package installs and does what it is supposed to do. None of them has reported any failure.


> The big challenge with packaging it for Debian is that it must suit to most
> setups and the aim of the package is to make it as easy as possible for the
> sysadmin.
> 
I understand this. However... this is a tricky issue. Does Debian expect that the package installs and automatically/automagically configures DSPAM? If this is the case then I would say that no other packing system out there does that. Debian would be the first one to manage this. Not that it is impossible to do that but how is the Debian packaging system supposed to know what kind of setup the sysadmin wants? There are many options how to run DSPAM and a packaging system is IMHO supposed to help/support the sysadmin to reach his goal but the sysadmin is the only one really knowing what he/she wants and no packaging system has telepatic capabilities and can read the mind of the sysadmin.


> I alone cannot test everything, but I was waiting to get more feedbacks from
> the various users of "my" unofficial packages before uploading it to the
> official archive.
> 
Aha. Okay. Then you should post to the DSPAM mailing list and ask users to submit feedback. The only problem I see in that is that most of them have installed DSPAM long time ago and have probably forgotten what problems they had during the install. Don't get me wrong. I don't think there is any issue with your package. But if Debian aims to be foolproof then you need feedback from users that have absolute no clue about DSPAM and are trying to install it. The feedback you get from those users are probably what you are looking for. Right?


> The experimental archive is actually for this kind of package - and as I am
> now certain the package is not totally broken, I'll upload it there to get
> even more feedback.
> 
> > I know the codebase pretty well and I would say that the current 3.9.x
> > series of DSPAM is by far the best DSPAM you can get today. I might be
> > biased but I think by looking at the GIT commit history you will see
> > yourself that many bug fixes, memory leaks and stability issues have been
> > resolved.
> 
> At first, I was also waiting for 3.9.1 to be released ;)
> 
Ach. Yesterday I had to lookup what this 'MIA' is. Now I know it. And now I can say that the other project members in the DSPAM community project are MIA too. Maybe I should move forward and ask on the DSPAM mailing list if the members/users are comfortable if I make a friendly take over and kick the other inactive admins out of the project? I would have released 3.9.1 since months but it's difficult to release a new version when our release manager, repo master, etc are not doing anything. I hold all the permission to do that all on my own but in 2009 we had assigned different positions to different persons for exactly that reason. Each of us is supposed to do something. But as usuall: When it comes to work then people somehow get lost. They are hiding and this is not good.


> I'll upload a snapshot of the current HEAD to Debian as it also adds a few
> fixes and improvements.
> 
> [...]
> > I am no Debian user and maybe I don't understand the whole thing.... but
> > why is it so hard to get an updated version of DSPAM into Debian? What is
> > the problem? How can I help? What needs to be done in order to allow
> > Debian users to enjoy a more recent DSPAM version?
> 
> I'd say the package is ready, though not widely tested and might still
> contain a few issues.
> 
Nothing is without issues. But if you have the possibility to put that package somewhere where other Debian users would be able to install it then why not? Exposing the package to a wider user base is a good way to get more feedback and make the package better. You have my full support. I will fully support you in the process needed to stabilize the package. I am not a Debian user and I definately lack the virginity needed to spot issues in the Debian package but should there be anything that can be fixed with some coding or documentation work from my part then I am here to help. I am pretty sure that together we can manage this task.


> Stevan, you also know I have almost no knowledge in C, which explains why I
> was at first reluctant in maintaing the package alone.
> 
I am not familliar with the requirements Debian is expecting from a package manager. But for packaging a software you are IMHO not required to know coding in C. Afterall you are just packaging that software and not extending it. Off course it helps if you know the language in what the software is written but be honest: do you think the packager for OpenOffice.org is knowing every single bit of the package? Probably not. So you should not put yourself under pressure. Important is that you know Debian and how to package for Debian.


> You have offered your help several times in the past, and I know I can rely
> on you in case something important happens. This is more than what any
> Debian Developer can expect from any upstream developer.
> 
I am still here and still more then willing to help getting a more recent version of DSPAM into Debian. This are not just words. I really am willing to dedicate time into the Debian package for DSPAM.


> I also realise I have been maintaining my unofficial packages for 3 to 4
> years without any major breakage (but with a much smaller userbase than
> Debian of course) [0]
> 
> > Regarding documentation: Tell me what needs to be rephrased or rewritten
> > or added and I will do it. Just send me patches for existing text or send
> > me new text and I will commit it. I think the DSPAM project never rejected
> > changes in the past regarding documentation.
> 
> I was refering to the documentation of the Debian package itself.
> 
What would that be? Can I read somewhere what additional documentation the Debian package is distributing? If I might ask you: what areas in the Debian documentation needs more work to satisfy the QA of Debian? Can I help anywhere?


> What most users expect is to get a fully working DSPAM setup very quickly. I
> know it is not possible to make it automatically, but I'd like to give them
> a good experience of both DSPAM and Debian.
> 
Most users have mainly issues because they don't understand the other software stack. Most of them are not familiar with one of the storage backends or with a MTA, etc... this is mostly the case. If a user understands all the other things, then installing and configuring DSPAM is usually a no brainer. Making the configuration easy can be made automatic (would require some time to write some kind of wizard for that). But maybe we are trying to make to much at once? Maybe a normal text document describing how to setup DSPAM would be a good start? I personally think that all information is already there inside the DSPAM package but for a beginner it's hard to get the big picture. So maybe a documentation describing in easy to follow steps how to setup a basic DSPAM installation would be a good start? This documentation should mention that the described way is just one of many possible setups and should be keept simple and basic and not touch the more advanced options. Pretty much like writing a documentation for Apache how to setup it to listen on 127.0.0.1 and serve one web page. Not going much into detail how to setup a gazillion of vhosts, advanced authentification with username/password in LDAP, load balancing, proxying, caching, etc... Something like that should IMHO be enough to get most users started to run DSPAM without overloading them with to much information.


> For example, the package now ships a sample of Apache configuration - I need
> to check it works on a clean install etc.
> 
This must be something Debian specific. The stock DSPAM package does not ship that Apache configuration. Only the documentation is mentioning one possible way how to configure Apache to serve the DSPAM Web-UI. Apache is a complex product. Writing just one global valid Apache configuration for the DSPAM Web-UI is practically impossible. God only knows how users out there configure their Apache and writing a sample configuration to suit all possible scenarios is IMHO not possible.


> > Regarding confidence: The Rice University is using DSPAM since ages for
> > all their students. I think they have about 65'000 mail boxes that they
> > filter with DSPAM. If DSPAM would be unstable or unusable then they would
> > for sure not use it. Beside that the DSPAM mailing list is full of users
> > using DSPAM in various scenarios. Just recently Nate Custer from
> > Hostgator.com said on the DSPAM mailing list that they filter mail for 3
> > million mail boxes with DSPAM. If that does not speak for DSPAM then I
> > don't know what would?
> 
> I use it at home for 3 users (including my 2yo son) which proves how
> scalable DSPAM is ;)
> 
You are doing it wrong! You should give him a fresh installed Debian system and tell him to install and configure DSPAM on it. If he manages this then your package is good. If not then you need to improve the package :)



> Cheers,
> Julien
> 
-- 
Kind Regards from Switzerland,

Stevan Bajić


> [0] I had first begun working on backporting the existing packages for
> Sarge, then have packaged 3.8.0 a few months after it was released by SN.
> 
> -- 
>   .''`.   Julien Valroff ~ <julien at kirya.net> ~ <julien at debian.org>    
>  : :'  :  Debian Developer & Free software contributor
>  `. `'`   http://www.kirya.net/
>    `-     4096R/ E1D8 5796 8214 4687 E416  948C 859F EF67 258E 26B1