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). > >>>> 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. 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 > >> - 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 ------------------------------------------------------------------------------ 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
