Re: Dspam dev status

On Oct 1, 2010, at 1:07 AM, Tom Hendrikx wrote:

> On 01/10/10 08:50, Eric Bischoff wrote:
>>> I'd be more pessimistic on this figure. The hash driver seems to  
>>> be broken
>>> and I do not think another release should be done while it isn't  
>>> fixed.
>>>
>>> However, I really think this should be fixed before a new release  
>>> can
>>> happen.
>>
>> Why is it so important? Because this is the default driver for  
>> Debian, Ubuntu and compatible distros. That means that basically,  
>> out of the box, dspam does not work as it should.
>>
>
> I think I have to disagree here. Release early, release often is imho
> the best way to work. 3.9.1 has some improvements over 3.9.0, and  
> major
> improvements over 3.6.8/3.8.0.
>
> If the hash driver is broken in 3.9.0 (current stable release, no  
> matter
> what the debians of this world tell us) and equally broken in 3.9.1,
> that is bad and maybe a shame, but no reason to hold back the
> improvements in other parts. 3.8.0 was OK (I think), but debian has no
> stable packages for it. I do not want to neglect debian (derative)  
> users
> or ppl like Julien who are working hard to get newer DSPAM versions  
> into
> debian, but there is no setback for debian users when releasing a new
> version (as in worst case scenario  debian will stay at 3.6.8) and  
> only
> improvement for others.
>
> After 3.9.1, start working on the hash driver and 'dedicate' the 3.9.2
> release to the hash driver.
>
> In both scenarios (3.9.2 gets released after some new devs stepping  
> up;
> or 3.9.1 will be the last release before the project going back to
> sleep), the users that would benefit from the improvements are served.
> At all times, people that have issues with newer releases have the
> option to downgrade to < 3.9.0 (which might also be a shame, but might
> be a needed advice when there is no manpower to fix what is broken).
>
> With a release of 3.9.1, nobody forces the users to run git HEAD or
> other kludges that seem unreliable to many, and regular packages can  
> be
> provided by distributions that are willing to do so. This grows
> acceptance and userbase, and it does not leave the improvements to rot
> in the repository.
>
> --
> My 2 cents,
> 	Tom

+1

3.9.1 solves problems for Mac OS X. It's a shame to have to wait for  
all other issues to be resolved before taking advantage of work  
already done.

// Brad

------------------------------------------------------------------------------
Start uncovering the many advantages of virtual appliances
and start using them to simplify application deployment and
accelerate your shift to cloud computing.
http://p.sf.net/sfu/novell-sfdev2dev