It was Saturday morning 2:00 am when I published the tarball. So what’s special?
This is the first additional release past the regular stable of GNOME 2.24.3. We saw that the 2.24.x series brought regressions due to the disk summary work. With every stable release we made it better and we thought it might be good to continue this and add two more releases on stable branch. These are the dates and 2.24.4 is already out
2.24.4 on Jan 30
2.25.5 on Feb 25
Thx to “ever great” Milan Crha for hacking out sqlite/fsync/ext issue which hurt our performance a lot. He wrote an awesome piece of sqlite vfs similar to FF’s vfs but a lot simpler which improved performance by 75% atleast. And thanks to David Ronis (huey) for some fine bugs which saved 2.24.4 and thx to Srinidhi who gave me the ultimate NEWS generation script which just did everything automatically. It’s a bit buggy but should be better in sometime. I would push Srinidhi to share it somewhere , it would be useful for a lot of people.
Pretty late blog, but really busy. I landed in Bangalore on July 14 8am to attend a 5 day out-door training starting at 10am. Lucky that the timezone difference isn’t very bad, I happened to manage with my training.
- Nice parties and thanks to all their sponsors and GNOME.
- Had nice discussions/talks with Michael, jpr, hpj, Miguel, Aaron, Scott and lot of other hackers
- Announced about the Evolution licensing change
- Had a couple of talks at GUADEC
- Nice chats with Muelli, jrb, thomas, philip, jorgen
- Attended lots of talks
- Stuck in a training till friday on project management training.
- Merged on-disk summary with trunk and guess what trunk must be broken for few/most cases. We will shape it well.Blame me/sankar if you see lots of warning on compilation, we explicitly added ‘#warnings’ for lots of stuffs to make sure we fix it instead of growing FIXMEs in the code. We ported most of the providers. Didnt do much for imap4 provider. But will do for it also post 2.23.5 which is on Monday. (Sorry fejj, too busy, so we delayed it). Any other camel provider like evolutin-brutus needs to be ported. I had a live demo at guadec on this and I have some graphs which I collected during my demo. I will attach at the end of the blog.
I had a fixed set of data for Evolution, couple of accounts and 2 vfolders which sort of fetches from all these folders. In total 200,000 mails.
Evolution 2.23.4 (before the merge)
Evolution 2.23.5 (after the merge)
Sankar already did a post on how it is done. I got these from massif, I know these arent exact but the comparison sort of shows difference/improvements.Evolution sort of releases unused memory over a period of time when you move away from folders and vfolders queries from db and loads counts. So nothing is loaded except what you see. But there are some issues lying around with the sqlite memory cache free, because of which at times it goes 100% cpu on to allocation of memory during sqlite commit. So Im sort of disabling all memory drop thread for 2.23.5 and would get them to shape during 2.23.6 or so. We have added lots of debug and g_assert(0) at few places to capture some important traces/issue so bear with us in 2.23.5 if it crashes more. File all your bugs to bugzilla and add to the tracker bug. All would be fixed and Evo 2.24 would be slim and rock solid.
Johnny and me were discussing some Evolution plugin idea and I said, it would be nice, if we can do it in Python. It is easier to write, as well as to install than a rpm/binary. He told me that he will do it over night, and I said NOT POSSIBLE and I promised to treat him, if he does it over night. I also made it clear that if he fails to do, he would work the next day with out pay
Next day lunch…
I treated him. I went to office to see that I got a mail from Johnny at 5am attaching the patch for Python EPlugin loader and a hello-world python plugin.
Evolution 2.24 should feature it and it should be much really easier to write and share Python EPlugins. Thanks to Johnny for the cool thing. Now everyone ask Johnny, when he is gonna commit it