2010-March Archive by Thread
Messages are ordered newest-to-oldest in this index. The newest
threads will be at the top of this page, the oldest will be at the bottom.
Within a single thread, the first mail note is the START of the
thread; the notes following that are in the chronological order of
when they were received. So globally, newest messages are at the top,
but within a thread, the oldest (the start of the thread) is at the
top.
If you think about it, it is confusing. Just go with the flow and everything will be all right.
[no subject],
Unknown
[Evolution-hackers] evolution 2.28 does not load calendars anymore,
Thomas Mittelstaedt
[Evolution-hackers] Build failure in evolution 2.30.0 (was Re: Patch for Evo 2.30 - size of mail sidebar),
Vincent Untz
[Evolution-hackers] build Evolution with jhbuild - unsuccessfull result,
Ivan A. Kostyuk
[Evolution-hackers] Bug Day : March 25-26,
Akhil Laddha
[Evolution-hackers] evolution master does not build in evolution/modules/network-manager,
Thomas Mittelstaedt
[Evolution-hackers] Extending Evolution,
Matthew Barnes
[Evolution-hackers] Evolution branched for GNOME 2.30,
chen
[Evolution-hackers] Build failure on git HEAD,
Paul Smith
[Evolution-hackers] evolution master does not build,
Thomas Mittelstaedt
[Evolution-hackers] Support for 'givenName' LDAP attribute,
Robert Markula
[Evolution-hackers] Problems with Migration from 2.28.4 to 2.30 (master): calendar, task, memo not there,
Thomas Mittelstaedt
[Evolution-hackers] Rebooting ChangeLog files in 3.x,
Matthew Barnes
[Evolution-hackers] Raw access to message,
Stefan Schulze Frielinghaus
[Evolution-hackers] Trusted certificates store,
ext-johan.groth
[Evolution-hackers] cursos online cursos video aulas,
David
[Evolution-hackers] GSettings Hackfest + Account Storage,
Matthew Barnes
Re: [Evolution-hackers] edbus branch review ...,
Travis Reitter
[Evolution-hackers] looong blockup in the UI ...,
Michael Meeks
[Evolution-hackers] cursos online cursos a distancia online,
David
Re: [Evolution-hackers] camel-folder-summary locking ...,
Michael Meeks
[PATCH] Fix unpleasant issue with (remove_item) more elegantly. Instead of taking an untaking the ref-lock thousands of times, and trying to free messages inside the loop (while cobbering their uid to encourage message_info_free not to do an unsave hash table removal, inside the g_hash_table_foreach_remove loop). Instead - we now just build a list very quickly of the messages we want to drop. As such, the hash table iteration will be ~instant, and we do not need to take / drop the lock each iteration, simplifying and perhaps accelerating the code. We then free the messages later before releasing the summary lock.,
Michael Meeks
Mail converted by MHonArc