On 08/06/11 07:54, Stevan Bajić wrote:
> On Tue, 07 Jun 2011 16:58:58 +0200, Nicolas Grekas wrote:
>
>> Hello,
>>
> Hello Nicolas,
>
>
>> I'm a huge fan of the "release early, release often" moto.
>>
This counts for me too :)
>> Why not release 3.9.1 asap, asis ?
>>
> because many people are involved in releasing a DSPAM release. It's not
> just one person saying "Now I am going to release a new version of
> DSPAM". Anyway... the funny thing is that this week we have started on
> the project admin mailing list to talk about doing another release of
> DSPAM.
>
When DSPAM was ressurrected from the Sensory Networks impasse some time
ago, a team stepped up and responsibilities were spread over these
people. The reality as I see it today (and some time before) however is
that most of these people have no more time to spend on DSPAM (some of
them did not even take time to write a decent "sorry but I have to step
down" e-mail, but that's another discussion).
This means that if we want DSPAM to show progress to the general public
(i.e. put out a release once in a while in stead of advising interested
parties to run a git-based install), we will need to get things done
ourselves. There are some people still actively working on DSPAM, and
there are people who would like to see a release, and do some work on that.
>> It is also really bad that on sf.net, last version is 3.9.1 "RC1"!
>> dated
>> from almost one year :(
>>
> This is not true. If you want the absolute newest version then you can
> use GIT Master. That one is as well available from sf.net.
>
The point is that people not familiar with DSPAM, want to go with safe
and sound. GIT master does *not* sound safe and sound, a release
candidate might be safe for some persons, but only regular releases work
for everyone.
Added to that: a release candidate implies that a release should be
imminent, it a candidate to be *released*. Having an RC but no final
release with a year in between, is i.m.h.o. a signal that something
might be wrong with the project.
>> Reading the list for several month, I understood that the actual code
>> is
>> not perfect,
>>
> Nothing is perfect. Ever! But since I got your attention: What do you
> consider as 'not being perfect' regarding the current code?
>
>
>> but that's not enough a reason to wait one more year. Just document
>> the
>> bugs, and lets fix them for 3.9.2!
>>
> 'lets fix them'? Does that mean you would help the DSPAM community with
> coding? That would be terrific! We need more coders contributing code
> and/or submitting patches.
>
Stevan: note that he says 3.9.2. I gues the OP means that we should
release 3.9.1 as-is, and move on to 3.9.2 with the outstanding bugs.
>> But I also value long term viability of the code base... What about
>> this
>> if even the already done work is not pushed outside ?
>>
Exactly.
What about making a plan to do another release? I don't know what
exactly needs to be done, but I guess we could make a start:
- write up a release todo list (this does *not* include bugs)
- execute it with people that want to help *now*
- release git master as 3.9.1-rc2
- ask the dspam-user ppl that run 3.9.0/3.9.1-rc1 or git to test it
- fix minor bugs reported against rc2, then release 3.9.1
- postpone major bugs to 3.9.2 or even 4.0 (whenever that may be)
I'm surely willing to put some time into this.
--
Regards
Tom
------------------------------------------------------------------------------
EditLive Enterprise is the world's most technically advanced content
authoring tool. Experience the power of Track Changes, Inline Image
Editing and ensure content is compliant with Accessibility Checking.
http://p.sf.net/sfu/ephox-dev2dev
_______________________________________________
Dspam-devel mailing list
Dspam-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dspam-devel
