Re: [Evolution-hackers] Evolution 2.32.0 and pop3 server error
On Sat, 2010-10-16 at 14:17 +0300, Dmitry Korzhevin wrote: Has anyone come across a bug in Evolution 2.32.0: Storage POP3 does not use a hierarchical folder structure Hi, I'm not sure what you mean with that. POP3 had never use any folders, as far as I know, it has only one, the Inbox, which can be fetched and operated with. Bye, Milan ___ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... http://mail.gnome.org/mailman/listinfo/evolution-hackers
[Evolution-hackers] Merging the collaboration providers in a single package
Hi, We had discussed about merging the collaborative providers such as evolution-exchange, evolution-mapi, groupwise, kolab and evolution-ews (on development) into a single package in previous community meeting. There are certain advantages and some concern areas in it, let me summarize them on what we discussed in the community meeting (http://projects.gnome.org/evolution/meeting-logs/2010-09-15.shtml), Advantages of having the providers in a single package: + All the API updates can be adapted to the providers and made sure all the providers compile. + Packagers can looks for updates from one package rather than evolution-groupwise, evolution-exchange, evolution-ews, evolution-kolab etc. Concern areas: + We may have to be pruning some backends if there are no bug fixes and if its not kept alive (for eg: google backend was replaced with caldav for the same reason) + The bugs from various packages have to be moved to a single package in bugzilla. Of-course some authors third-party external backends may not be interested or may not be possible due to some licencing issues. But we can at-least facilitate it if the authors and evolution maintainers are interested in maintaining it. The other solution was to maintain all exchange providers in a single package, merging evolution-exchange, evolution-ews and evolution-mapi into a single package. Other collaboration providers like evolution-groupwise and evolution-kolab (yet to be upstreamed) will remain as separate packages. My personal opinion is to club all the collaboration providers into a single package would be good. It would be good if we discuss the pro's and con's more deeper and involve packagers as well while moving on to a solution. Thanks, Chenthill. ___ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Merging the collaboration providers in a single package
On Mon, 2010-10-18 at 12:10 +0530, chen wrote: The other solution was to maintain all exchange providers in a single package, merging evolution-exchange, evolution-ews and evolution-mapi into a single package. Other collaboration providers like evolution-groupwise and evolution-kolab (yet to be upstreamed) will remain as separate packages. If we -have- to glob providers together I would prefer the alternate solution: merge all the Exchange providers into one git module, break GroupWise out from E-D-S into it's own git module, and leave the rest alone. This is not unlike the recent gnome-games debate on desktop-devel-list, except that we already have shared libraries for the common parts with fairly stable APIs (libebook, libecal, etc.). Jon's comments on the gnome-games issue reflect my own for this one: http://mail.gnome.org/archives/desktop-devel-list/2010-October/msg00049.html ___ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Merging the collaboration providers in a single package
On 10/18/2010 at 07:01 PM, in message 1287408711.3126.11.ca...@localhost.localdomain, Matthew Barnes mbar...@redhat.com wrote: On Mon, 2010-10-18 at 12:10 +0530, chen wrote: The other solution was to maintain all exchange providers in a single package, merging evolution-exchange, evolution-ews and evolution-mapi into a single package. Other collaboration providers like evolution-groupwise and evolution-kolab (yet to be upstreamed) will remain as separate packages. If we -have- to glob providers together I would prefer the alternate solution: merge all the Exchange providers into one git module, break GroupWise out from E-D-S into it's own git module, and leave the rest alone. This is not unlike the recent gnome-games debate on desktop-devel-list, except that we already have shared libraries for the common parts with fairly stable APIs (libebook, libecal, etc.). Jon's comments on the gnome-games issue reflect my own for this one: http://mail.gnome.org/archives/desktop-devel-list/2010-October/msg00049.html I prefer not to have every provider in its own module. If we make changes in the baseclass, it will be ignored and won't go into unmaintained providers. More providers translates to more work for packagers downstream and also during the release time for maintainers as well, with not much benefits. Just my 2 cents. Sankar ___ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... http://mail.gnome.org/mailman/listinfo/evolution-hackers
[Evolution-hackers] Remove duplicate plugin
Hi all, is there somebody who made working the Remove duplicate plugin on Evolution 2.30 and above? I have Mandriva 2010.1 One and evo 2.30.3 with KDE 4.4.3. Sometimes my evo downloads all my emails twice and as a result I get hundreds of duplicate emails. In the past I used to use the plugin but on evo 2.30 and above the plugin doesn't work. I asked the developers and they told me, that I have to do a patch above source code. Unfortunately it didn't work because it is too old. One of them gave me your email with maybe it help. Does onyone have patched or even created rpm package for mandriva? Thank you for your reply. Ondrej ___ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... http://mail.gnome.org/mailman/listinfo/evolution-hackers
