Re: [Evolution-hackers] Future of eds bindings
On Sun, 2008-08-17 at 19:30 +0100, Ross Burton wrote: On Sun, 2008-08-17 at 20:18 +0200, Patrick Ohly wrote: Do you plan to do that before replacing Bonobo in the mainline Evolution? Yes, finding out why getchanges() is so damn slow is on the list of things to do. I'm afraid speeding up the underlying C implementation in the file back end will only delay the inevitable: as the number of contacts grows, there'll always be a point when the time out strikes too early. It's simply not possible to squeeze an O(n) (or worse) implementation into a fixed amount of time in all cases :-/ Now in this case perhaps the implementation can be sped up so much that it doesn't matter. But in some other cases (backends which communicate with remote servers?) it will remain a problem. IMHO the underlying problem is that Bonobo/ORBit/CORBA allow calls which run for an unlimited amount of time whereas DBus doesn't. Therefore a simple mapping of CORBA calls to synchronous DBus calls will always be problematic. Do you think that mapping all synchronous libebook/libecal calls to asynchronous communication via DBus would be possible? -- Bye, Patrick Ohly -- [EMAIL PROTECTED] http://www.estamos.de/ ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] bug fixing in stable 2.22.x branch
Patrick Evolution follows GNOME release cycles, which has just three dot releases on the stable branch (2.22.3). And after that only for DoS/Vulnerability fixes there will be dot releases. Distros shipping 2.22.x will pick patches from trunk/2.22.x and apply as and when required. (Atleast for OpenSUSE, I/my team does that). Im sure Ubuntu/Fedora too does the same. If it is a really issue, may be mailing the distributors list on picking some patches for Evo/Eds may help. -Srini. On Tue, 2008-08-19 at 18:41 +0200, Patrick Ohly wrote: Hello, I have a question primarily to the maintainers of the various Linux distributions which include Evolution 2.22.x (Ubuntu 8.04 LTS, Debian Lenny), but also to the Evolution hackers: the latest stable release, 2.22.3.1, still contains bugs. There are different ways to deal with this: 1. Evolution upstream continues to apply bug fixes to the 2.22.x as long as important distributions use that. 2. Maintainers of packages apply patches locally, without or with help by Evolution upstream. Upstream could help with bug tracking. What's the current practice? It seems that upstream has already stopped updating the 2.22 branch and bug fixes are only applied to trunk [1]. I'm bringing this up because at least one of the bugs will become critical in September: as noted this week [2], the conversion of system time zone information into libical time zone information (as used by Evolution) yields an end of summer time which is one week too early for Western Europe. It might also be incorrect for other countries and for the beginning of summer time. That's particularly disappointing because the work on improving time zone support [2] was supposed to solve such issues. Now it looks like Evolution will fail to display events at the right time - once again! In addition to this problem I'm sure there are other bugs which could be included in another 2.22.x release. The broken Exchange Connector contact change tracking [1] is one example. [1] http://bugzilla.gnome.org/show_bug.cgi?id=546934#c2 [2] http://bugzilla.gnome.org/show_bug.cgi?id=548268 [3] http://www.estamos.de/blog/2008/06/22/time-zone-handling-in-evolution/ ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] bug fixing in stable 2.22.x branch
On Tue, 2008-08-19 at 18:41 +0200, Patrick Ohly wrote: Hello, I have a question primarily to the maintainers of the various Linux distributions which include Evolution 2.22.x (Ubuntu 8.04 LTS, Debian Lenny), but also to the Evolution hackers: the latest stable release, 2.22.3.1, still contains bugs. There are different ways to deal with this: 1. Evolution upstream continues to apply bug fixes to the 2.22.x as long as important distributions use that. 2. Maintainers of packages apply patches locally, without or with help by Evolution upstream. Upstream could help with bug tracking. What's the current practice? It seems that upstream has already stopped updating the 2.22 branch and bug fixes are only applied to trunk [1]. Evolution follows the GNOME development schedule [1] which allows for three updates to a stable release per six-month development cycle. Generally thereafter, all work is concentrated on trunk in preparation for the next stable release (2.24 for this cycle, due in late September). Distros are free to make additional changes to their packages beyond the third stable update (backporting patches, fixing security issues, etc.). I'm not sure the GNOME release team _prohibits_ making additional stable updates beyond the third scheduled point release, but it's generally not done given our limited manpower. Matthew Barnes [1] http://live.gnome.org/TwoPointTwentythree/ ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] bug fixing in stable 2.22.x branch
Hi, I'm not speaking on behalf of Evo maintainers or distributors, just my personal opinion. Am Dienstag, den 19.08.2008, 18:41 +0200 schrieb Patrick Ohly: I have a question primarily to the maintainers of the various Linux distributions ...that would be the distributor-list (it's not really well-known). http://mail.gnome.org/mailman/listinfo/distributor-list which include Evolution 2.22.x (Ubuntu 8.04 LTS, Debian Lenny), but also to the Evolution hackers: the latest stable release, 2.22.3.1, still contains bugs. So do the latest released $MODULE tarballs for GNOME 2.20 or GNOME 2.14... There are different ways to deal with this: 1. Evolution upstream continues to apply bug fixes to the 2.22.x as long as important distributions use that. ...and to 2.20 or 2.14 (remember Debian?). Next problem: What is important? For example, Ubuntu's 8.04 (GNOME 2.22) provides 3 years support for desktop versions and 5 years for server versions. That means 2013, if we'd continue with our versioning system (we won't), this would mean working on GNOME 2.41 while still maintaining 2.22. IMO it's up to the distros to decide on their business models. Don't outsource the costs of additional support to upstream, please. :-) 2. Maintainers of packages apply patches locally, without or with help by Evolution upstream. Upstream could help with bug tracking. What's the current practice? It seems that upstream has already stopped updating the 2.22 branch and bug fixes are only applied to trunk [1]. GNOME 2.22.3 was the last planned GNOME release. After that it doesn't happen too often that maintainers (or distros) will ship another tarball from SVN. Applying patches to stable branch too is often considered too much work in SVN. For very important GNOME issues I sometimes sent a list of bugs patches to the distributor-list (though I've become a bit lazy in the last months due to work). So from my point of view you either want to ask the evolution maintainers for a 2.22.4 release, or ask the distributor-list to apply the patches locally and ship package updates for their users. I agree that the timezone bug you listed is important and should be dealt with. andre -- mailto:[EMAIL PROTECTED] | failed http://www.iomc.de/ | http://blogs.gnome.org/aklapper ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
[Evolution-hackers] MAPI backend
Hello, I'll soon be migrated to Exchange 2007 at work, so I'll have to get the MAPI backend working or I'll loose convenient access to the shared calendar. I don't have root access, therefore I compiled all the required components (Samba, libmapi, EDS, Evolution) from source. I haven't tried to run it yet. I ran into several compile issues (dolt uses += which my bash didn't support; include paths wrong for out-of-tree compilation) and have patches for them. Shall I submit them to bugzilla.gnome.org? Have the licensing issues been resolved? What's the recommended way to keep track of the MAPI development (known issues, current status, etc.)? Are the go-evolution pages kept up-to-date? -- Bye, Patrick Ohly -- [EMAIL PROTECTED] http://www.estamos.de/ ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] MAPI backend
On Tue, 2008-08-19 at 20:22 +0200, Patrick Ohly wrote: Hello, I'll soon be migrated to Exchange 2007 at work, so I'll have to get the MAPI backend working or I'll loose convenient access to the shared calendar. I don't have root access, therefore I compiled all the required components (Samba, libmapi, EDS, Evolution) from source. I haven't tried to run it yet. I ran into several compile issues (dolt uses += which my bash didn't support; include paths wrong for out-of-tree compilation) and have patches for them. Shall I submit them to bugzilla.gnome.org? yes please. Add evolution[mapi] in status whiteboard. Have the licensing issues been resolved? It is in progress. What's the recommended way to keep track of the MAPI development (known issues, current status, etc.)? Are the go-evolution pages kept up-to-date? http://www.go-evolution.org/MAPIProvider Yep , we try to keep this page updated. There is a #evo-mapi channel for this. Thanks a lot ! ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
