On Wed, 08 Jun 2011 10:00:55 +0200, Tom Hendrikx wrote: > On 08/06/11 07:54, Stevan Bajić wrote: >> On Tue, 07 Jun 2011 16:58:58 +0200, Nicolas Grekas wrote: >> >>> Hello, >>> >> Hello Nicolas, >> Hello Tom,
>> >>> I'm a huge fan of the "release early, release often" moto. >>> > > This counts for me too :) > I am on your line too. If it where up to me then I would make a more structured release cycle. I would at least deliver a sub release every 3 months (aka: 4 times a year) and in between release when ever something significant has been fixed. >>> 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 is a small point but currently it is the major drawback for the project. Technically I could release at any time and permission wise I have the possibility to do so. But I am not alone and I am not supposed to release or make my self the decision when to release. > 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. > I work pretty often on DSPAM but not so much on the version that is on SF (except if some one is reporting a serious bug). >>> 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. > Yes and no. Most people don't care about releases of DSPAM. They take whatever the package manager of their distro is packaging for them. > 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. > Yes, yes, yes. I am totally on your line. >>> 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. > Yeah. I saw that. He said that we should release 3.9.1 NOW and whatever bug/issue is open, can be targeted in 3.9.2. >>> 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 > I would like to release git master as 3.9.l and not do another RC. > - 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 > -- Kind Regards from Switzerland, Stevan Bajić > _______________________________________________ > Dspam-devel mailing list > Dspam-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/dspam-devel ------------------------------------------------------------------------------ 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
