On Wed, 08 Jun 2011 13:16:27 +0200, Tom Hendrikx wrote: > On 08/06/11 10:15, Stevan Bajić wrote: >> 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: > >>>>> 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. >> > > It seems that we have now 3 votes for 'release early, release often', > and no votes to postpone release until all/major bugs are fixed (or > any > other excuse for not releasing soon). > I really think that no one has anything about releasing more often. We are only here where we are because lack of time from some members. That's it. I don't think any one is against releasing more often nor do I think that any one of the admins is on purpose holding back the project.
>>>>> 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. >> > > To be quite honest, I think you're the only person left that works on > development, and Paul being involved in website/wiki/documentation. > > If there are other people involved, then let them speak up. They > should > be on this list, so of they don't respond, they don't count on them. > > If this means that there is work left to be done, then other people > will > need to take over. This will only happen if it is abvious that this > is > the case. There are some volunteers here (Julien, Nicolas, me, some > others maybe) but no obvious tasks open. > >>> 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. >> > > This does not work when they need help with something, join the > dspam-user list and get told to upgrade to something newer. > Especially > when they see all benefits that are available in a 3.6.8+ install > (debian/ubuntu example). Working around the package manager + distro > packages is bad enough, but doable with backports or other > distro-equivalents. Manual install including compilation of a tarball > of > git repo might be a bridge too far. > The DSPAM package in Debian is not any more that ancient (thanks to Julien). Ubuntu is another issue. > Anyway, since we all think alike, this is preaching for the converted > :) > ;) >>>>> 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. >> > > No real problems with that > Not that you think I want to avoid RCs. But about one year has passed since last RC and a lot of the hardcore DSPAM admins/users run anyway git master and judging from the past RCs... I don't think that we will gain much (if at all) new feedback/bugreports from a new 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) >>> > > > 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
