[Evolution-hackers] [Reminder] Evolution community meeting at #evolution-meet channel - oct 20 - 3:30 PM UTC
Hi, The meeting goes as follows, * Update on EWS plan * Project updates * Discussion on queries/decisions * Individual updates - 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 ___ 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 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 09:21 -0600, Sankar P wrote: 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 The control/ownership of the code can be made clear using provider-level maintainer-ship (like groupwise, exchange, kolab2 maintainers etc.) inside a single package. Of-course package is one, but with independent sub-modules and owners. Is there any other disadvantage or point of concern ? 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. I agree. I would not term as un-maintained providers. If they are really un-maintained, which means many bugs exist and people are not able to use it, it has to be pruned at some point. But certainly I see advantages to have the providers in a single package which would help us adapt to the API changes well, translations could be shared, packagers can look for updates for one package and maintainers would have less burden in releasing many packages. - Chenthill. 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 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 Tue, Oct 19, 2010 at 04:31, chen pchenth...@novell.com wrote: On Mon, 2010-10-18 at 09:21 -0600, Sankar P wrote: 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 The control/ownership of the code can be made clear using provider-level maintainer-ship (like groupwise, exchange, kolab2 maintainers etc.) inside a single package. Of-course package is one, but with independent sub-modules and owners. Is there any other disadvantage or point of concern ? I somewhat agree with Matthew on this one. If we glob all the providers together: a) Distro A doesn't want to support Provider X. You'd say we'll have a compiler option to not compile X. Why does Distro A even need the sources for X (and eventually ship it too)? b) If we put all the providers together, and this is from what I've seen happening, there is this tendency for code to get duplicated. Along with good designs, sometimes bad designs also get duplicated. 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. If a module has an owner, how is it unmaintained? As a packager, if we do glob the modules together, the first thing that would happen is a split-up of the built files into their own sub-packages in the spec. How is this any different from having two separate packages? Just my 2 cents. I agree. I would not term as un-maintained providers. If they are really un-maintained, which means many bugs exist and people are not able to use it, it has to be pruned at some point. But certainly I see advantages to have the providers in a single package which would help us adapt to the API changes well, translations could be shared, packagers can look for updates for one package and maintainers would have less burden in releasing many packages. Turning it around the other way, if a change in the globbed package means nothing to the provider I'm using or interested in, what's in it for me to update the package? :-) If a module is maintained, the API changes will eventually get there. Besides, you shouldn't be changing the base API that often anyway ;-) -Suman ___ 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
I somewhat agree with Matthew on this one. If we glob all the providers together: a) Distro A doesn't want to support Provider X. You'd say we'll have a compiler option to not compile X. Why does Distro A even need the sources for X (and eventually ship it too)? For the same reason how it works in other projects, say Kernel. The linux kernel has dozens of file systems. Most of the distros are interested in a few of the filesystems only. But the reason why all are kept in the tree is because the changes will be updated in all the filesystems. It is easier to implement new build policy changes as well, if everything is in one place. b) If we put all the providers together, and this is from what I've seen happening, there is this tendency for code to get duplicated. Along with good designs, sometimes bad designs also get duplicated. Yes. Absolutley. In the same way, once a bad design is identified in one module and fixed, there is more chance of it getting fixed in rest of the providers as well, if it stays in the same tree. 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. If a module has an owner, how is it unmaintained? The maintainer can go on a leave or focus on some other urgent new activity etc. (Say EWS). But I agree with Chen that Unmaintained is a poor word selection. As a packager, if we do glob the modules together, the first thing that would happen is a split-up of the built files into their own sub-packages in the spec. How is this any different from having two separate packages? Packager Hat Why ? We wont. We will just get one tarball update when released and build that with whatever configure options that suits our distro. We won't attempt to divide further. Like for instance, for kernel, we have only: kernel-pae/x86_64.rpm and no kernel-fs-ext3.rpm, kernel-fs-btrfs.rpm etc. All filesystems are inside the kernel.rpm /Packager Hat Just my 2 cents. I agree. I would not term as un-maintained providers. If they are really un-maintained, which means many bugs exist and people are not able to use it, it has to be pruned at some point. But certainly I see advantages to have the providers in a single package which would help us adapt to the API changes well, translations could be shared, packagers can look for updates for one package and maintainers would have less burden in releasing many packages. Turning it around the other way, if a change in the globbed package means nothing to the provider I'm using or interested in, what's in it for me to update the package? :-) None. Agreed. If a module is maintained, the API changes will eventually get there. Besides, you shouldn't be changing the base API that often anyway ;-) Agreed. Ideally ;-) 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] If an account changes, who regenerates the services?
Hi, all, I'm trying to unwind some code in Camel and in Evolution. The problem I have is that if you change an email account's extra options (e.g. imapx's apply filters to new messages), then those changes don't take effect until you restart Evolution. That option is a filter parameter in a CamelURL - the URL for the IMAPX service. As far as I can tell, the only place where an IMAPX service gets this URL is at construction time. However, a breakpoint at imapx_construct() only gets hit when I start up Evolution, not afterward (e.g. after changing the account's options in the account editor). There is a lot of code around the account editor to apparently propagate changes. But I'm rather lost in the structure. em-account-editor changes the EAccount in emae_commit(), by calling e_acount_import(). Then it does e_account_list_change(). Both of those functions emit signals about something changing. That's where I'm lost. Does anyone know what links both parts of the code - the account editor and the actual construction of Camel services? Thanks, Federico ___ 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] If an account changes, who regenerates the services?
On Tue, 2010-10-19 at 14:10 -0500, Federico Mena Quintero wrote: I'm trying to unwind some code in Camel and in Evolution. The problem I have is that if you change an email account's extra options (e.g. imapx's apply filters to new messages), then those changes don't take effect until you restart Evolution. That option is a filter parameter in a CamelURL - the URL for the IMAPX service. As far as I can tell, the only place where an IMAPX service gets this URL is at construction time. However, a breakpoint at imapx_construct() only gets hit when I start up Evolution, not afterward (e.g. after changing the account's options in the account editor). There is a lot of code around the account editor to apparently propagate changes. But I'm rather lost in the structure. em-account-editor changes the EAccount in emae_commit(), by calling e_acount_import(). Then it does e_account_list_change(). Both of those functions emit signals about something changing. That's where I'm lost. Does anyone know what links both parts of the code - the account editor and the actual construction of Camel services? The 100,000 ft. answer is that trying to represent an account and its various options as a URL string is a broken concept and another deep design flaw in Camel. Change any option that results in a different URL string and Camel treats it as a completely new account, sets up all new cache storage for it, and doesn't even clean up the old cache. Camel needs to have some kind of account object onto which meta-data can be added and altered. But to actually answer your questions, CamelStores are loaded from EAccounts at startup in mail/e-mail-store.c:mail_store_load_accounts(). Once loaded, the CamelStore object is added to the EMFolderTreeStore, which serves as the model for the folder tree view in the side bar. EMFolderTreeStore responds to the account-changed signal by removing the CamelStore object associated with the changed EAccount, and loading a new one. I'm not exactly sure how that's handled within Camel, but my guess is this is the source of the problem. That's the only place I'm aware of that anything meaningful happens. The other account-changed handlers are for custom widgets that just list the accounts, like EAccountComboBox which appears in the composer. Hope this helps. ___ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... http://mail.gnome.org/mailman/listinfo/evolution-hackers
