On Sat, 23 May 2009 22:07:21 +0200 "Steve" <[email protected]> wrote:
> > I know, I hope you're OK now. > > > I am. Thanks for asking. > > > > :-) There's no such thing as a to verbose commit message. > > > LOL. Yes. You are right :) Why does your comment remind me of my real > work and ITIL? Why? :) :) :) :-)) > > Speaking of which: maybe it's good idea to reference the commit hash > > ie. instead of 'Updated CHANGELOG' > > Update for 3d69325d2ac31d03926f529820acfd0b75c5439b, > > 45f829160366a5bdbaefda64ed3be61e1b1953fd > > .... > > > How do I know the commit hash before committing? You updated the CHANGE log based on your previously commits. So you have their hashes, no? > > Merge "down" in stable/release branches (RELENG*). > > We're using MASTER as testing ground for everything: bug-fixes, > > improvements, small, big changes. Supposedly they will be tested > > before merged merged down, the idea being to have the stable > > branches OK at all the times. > > > Okay. Now I understand. > > Regarding stability: I tested all the stuff I have submitted on my > Gentoo box with GCC 4.4.0 and glibc 2.9_p20081201 [ .. compiling on gentoo .. ] > So no big issues except some warnings which where there before my > submits. Version output is as well okay: [ .. ] > My biggest concern was the huge MySQL driver patch but everything > works as expected and faster then before (doing a classification of > 100 mails in below 4 seconds on a Intel Pentium 4 CPU 2.80GHz with > MySQL Community Edition v5.1.34 and the mails are stored on a > GlusterFS v2.0.1 with replicate and NUFA): Nice ! [ .. ] > And the memory leaks are gone as well :) [ .. valgind .. ] > I have to take time to iron out the last part (the one still > reachable) but for the moment at least there are no definite memory > leaks when using just the normal DSPAM client. When running in agend > mode, then there are no leaks at all: [ .. valgrind .. ] > The original DSPAM 3.8.0 code had allways small memory leaks. I think > somewhere in 2007 or even 2006 I started slowly (when ever I had > time) to hunt and nail them down. In the middle I started even to do > the same thing for the PostgreSQL storage driver but had not enough > time to bring it up to the same level as the MySQL storage driver. I > think we as DSPAM developers must give enough focus on getting all > the storage drivers to be free of memory leaks. Funny thing that I was working on a few of same issues you seem to have committed; I'll compare my code with your tomorrow. Drop me an email with what you are working on please, no reason to duplicate our work. WRT storage drives you are very right, of course, since they affect all our users. I guess PG should be next, then hash. > > Pushed down in RELENG_M > > The interval is just so that I can do a script that will send > > remainders and it's at committer's discretion since he should know > > best how much testing is needed, how big destabilizing impact it > > can have, etc. As a rule of thumb I'd say: > > - 1 day for comments, docs, small changes > > - instant for security fixes > > - 1-3 weeks for bigger changes (I was one of your commits with one > > week) > > > > Merging from RELENG_M to RELENG_M_m and RELENG_M_m_u would be done > > for the releases only (some days before we start a new release > > cycle). > > > The patches I sumitted so far are since years in usage by me and a > bunch of other people. So far I have not heard anything bad regarding > them. But I would apprechiate if more people could test them. Do you think it would be helpful to do weekly tarballs from master ? I'll have the FreeBSD-7-amd64 nightly builds enabled tomorrow and I should be able to get access to our non-i386/amd64 reference machines in a few days. > Especially on other platforms then x86/x86_64 and Linux. I would be > interessed to see if the patches work on BSD, MacOSX and/or on > non-Intel CPUs. > > When you write about "Pushing down in RELENG_M": What release would > that be? 3.8.1? Given the amount and type of changes we now have in MASTER, it would be 3.9 (you did bump the lib to 3.9.0 after all). -- IOnut - Un^d^dregistered ;) FreeBSD "user" "Intellectual Property" is nowhere near as valuable as "Intellect" FreeBSD committer -> [email protected], PGP Key ID 057E9F8B493A297B
signature.asc
Description: PGP signature
------------------------------------------------------------------------------ Register Now for Creativity and Technology (CaT), June 3rd, NYC. CaT is a gathering of tech-side developers & brand creativity professionals. Meet the minds behind Google Creative Lab, Visual Complexity, Processing, & iPhoneDevCamp asthey present alongside digital heavyweights like Barbarian Group, R/GA, & Big Spaceship. http://www.creativitycat.com
_______________________________________________ Dspam-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/dspam-devel
