Re: [Evolution-hackers] Removing libical fork, moving to new upstream?
>Mi Sep 10 2008 11:26:31 EDT von Chenthill in 00.Sent Items> an >Patrick Ohly >Betreff: Re: [Evolution-hackers] Removing libical fork, moving to new >upstream? > > >>> >>> > How would you feel about a global flag which tells libical how to >>> > allocate memory? >>> >>> The problem with that is that it is not possible to mix code which uses >>> the old and the new semantic. For example, a program or library which >>> uses libical directly, using the old semantic, couldn't be combined with >>> the Evolution libraries. >> > >Yes right. Its not possible to have the old semantic with changed memory >allocation. > >>> >>> To let old and new code coexists I would suggest the following approach: >>> 1. The Evolution patch gets applied, making the core functions safe >>> to use. >>> 2. The function implementations whose semantic has changed get >>> renamed; I kind of like the _r suffix, but _alloc or _copy would >>> also work. >>> 3. Under the old names small wrappers are added which establish the >>> old behavior again by copying the string into the ring buffer >>> and freeing the dynamically allocated one: this incurs some >>> overhead, but usage of these versions of the calls is >>> discouraged anyway. By using function attributes it would be >>> possible to trigger deprecation warnings for code which still >>> uses them. >>> 4. In the header file both variants are declared. >>> 5. In addition, ical.h also redefines the old names to the new >>> names if the HANDLE_LIBICAL_MEMORY define is set: Evolution code >>> already does that and therefore continues to work with such a >>> modified upstream libical without source code changes. >>> >>> I personally would prefer to avoid step 5 and rather do a search/replace >>> in Evolution, but Chenthill didn't like that. >> >Since we do really want to remove the fork and pick up packages from >upstream, I can change the apis in evolution related packages if a new >set of apis with some suffix is provided from libical upstream. > >The old patch is attached with bug 516408. You can find the patches at, > >http://svn.gnome.org/viewvc/libical?view=revision&revision=633 >and >http://svn.gnome.org/viewvc/libical?view=revision&revision=637 > > >thanks, Chenthill. > > > Since it doesn't make sense imho to mix old style and new style api calls in one application imho, and I hink we can deprecate the old style. It also should be exeptable to drop binary compatibility; raise the lib-version, and add one significant incompatible function here, which gets triggered, so distributors have to recompile applications. I think the oldstyle methods realy should just be wrappers in the headers, and I like the idea of hiding them via an define. We also have the new include schematic of having libical/ical.h than maybe this could be used to do it imlicit, so no define would be needed in the old case. Wilfried Goesgens___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Removing libical fork, moving to new upstream?
On Wed, 2008-09-10 at 08:18 -0400, dothebart wrote: > Since it doesn't make sense imho to mix old style and new style api > calls in one application imho, and I hink we can deprecate the old > style. We can deprecate it, but as you said yourself earlier, moving all developers over to the new API at once might not be possible, so the old one should stay around for a while. > > It also should be exeptable to drop binary compatibility; raise the > lib-version, and add one significant incompatible function here, which > gets triggered, so distributors have to recompile applications. Please try to avoid breaking backwards compatibility. I release SyncEvolution binaries and already have to compile three different versions just because of ABI changes; changing the libical ABI would add another version :-/ > I think the oldstyle methods realy should just be wrappers in the > headers, and I like the idea of hiding them via an define. Just to be clear, my proposal was to have them as normal functions under the old names (for backwards compatibility). They could be hidden by defines, but I don't like that because then someone reading code which calls libical cannot tell whether the code handles the memory correctly unless he also checks how it is compiled. Cut-and-paste could lead to memory handling errors. -- 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] Evolution: Taking forward...
Hello, Apparently I've been told that I have some code in evolution, despite having no memory of it. Anyway, since I assume you guys know better than I do, I guess I do. So in that case, feel free to relicense any of my code as outlined below. George Srinivasa Ragavan wrote: Hello guys, We have had a set of problems that we are carrying around for some time like : * Copyright assignments, which is not the best way looking for the future of Evolution. It sucks and sort of limits contributions to Evolution and we wanted to drop it. * The current licensing incompatibility issues of Evolution with Samba4/libmapi (GPLv3). Evolution needs to link with libmapi/samba4 for the new mapi based connector being developed for Exchange 2007. So here is the plan : * Drop Evolution copyright assignments and make it really easy to contribute to Evolution * Move Evolution licensing to "LGPL v2 and LGPL v3" to let us re-use the code more easily around the platform. This also moves us closer to Thunderbird's MPL/LGPL model. We think this is good for Evolution and (of course) we continue to invest in Evolution. We are also working to ensure we have the rights to re-license all of the code. We will do the licensing/header changes as we audit the code ownership situation. It would be really helpful if you can post a public/explicit mail with permissions to do it, or code pointers - if you think you wrote a piece of Evolution code & object. We are really excited about this and we feel this would really help Evolution a lot. We need your support now for making this change and to take Evolution to great heights. Thanks for your contributions and support. -Srini. ___ desktop-devel-list mailing list [EMAIL PROTECTED] http://mail.gnome.org/mailman/listinfo/desktop-devel-list -- George <[EMAIL PROTECTED]> If God did not exist, it would be necessary to invent him. -- Voltaire ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Removing libical fork, moving to new upstream?
Chenthill wrote: So it is better to inform all the stake holders about the change and let them depend on the library versions to decide whether to free the memory or not if they have a need to depend on the older versions of libical. I think no one deny to make the necessary changes knowing that the old API is not very stable. Atleast once I noticed the problem. I made this patch and made all the changes required in evolution, evolution-exchange and evolution-data-server. I would not really like to change them again with new APIS :) Although I agree that the new memory model is a vast improvement over the existing one, I think you may be underestimating the potential effects of telling dozens of downstream projects that they will have to rewrite their code *right* *now* in order to continue using libical. Many will respond by forking, or staying forked, which as I mentioned earlier is exactly the opposite of what we are trying to accomplish. How would you feel about a global flag which tells libical how to allocate memory? Surely you wouldn't mind adding one line of code during an initialization phase that tells libical "caller accepts the responsibility to free all returned strings" ?? (The ring buffer memory model, inferior as it may be, must still be the default in order to run existing code unmodified.) If this is acceptable, then would someone please point us to a patch which implements the memory management changes, and we'll apply an enhanced version of it with user-selectable memory allocation model added in. -- Art ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
