No worries, we're not on a strict release schedule. We can do point
releases at any time if you find that something needs to be updated.
Thanks for your continued involvement. We're really looking forward to
the final outcome.
-- Art
Chenthill wrote:
I was not able to try the upstream l
I was not able to try the upstream libical yet. I am right now packed
with some other work, so I will try to get this done as soon as
possible. Suddenly the weekends have gone out of my hands as I have to
move out of station to places that do not have internet connectivity.
Either me or suman will
I have applied Chenthill's memory management patches (only to the
'libical' directory and to the examples -- still have to do the
'libicalcap' and 'libicalss' directories) using function names ending in
"_r".
IMHO, HANDLE_LIBICAL_MEMORY can be removed.
Ok folks, it's done ...
The rema
On Thu, 2008-09-18 at 22:52 -0400, IGnatius T Foobar wrote:
> >> I have applied Chenthill's memory management patches (only to the
> >> 'libical' directory and to the examples -- still have to do the
> >> 'libicalcap' and 'libicalss' directories) using function names ending in
> >> "_r".
> > I
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.
Many of you have probably already read this on the libical mailing list,
but just in cas
Patrick Ohly wrote:
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 co
Hello!
A while ago in this thread I argued in favor of keeping the old
functions around with their old semantic to preserve backwards
compatibility. I still stand by that logic for *libical* users.
But later it occurred to me that for *libecal* users this is an API
change because code which was c
On Tue, 2008-09-16 at 09:37 -0400, IGnatius T Foobar wrote:
> > 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.
> >
> Many of you ha
>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
>&
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 a
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
On Tue, 2008-09-09 at 18:00 +0200, Patrick Ohly wrote:
> On Tue, 2008-09-09 at 09:12 -0400, IGnatius T Foobar wrote:
> > 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
> >
On Tue, 2008-09-09 at 09:12 -0400, IGnatius T Foobar wrote:
> 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
On Mon, 2008-09-08 at 23:55 -0400, IGnatius T Foobar wrote:
> Patrick Ohly wrote:
> > In the upstream libical certain functions return char * pointers into
> > memory stored in ring buffers. The caller must not free those pointers.
> > The drawback is that the life time of those strings is not pr
Patrick Ohly wrote:
In the upstream libical certain functions return char * pointers into
memory stored in ring buffers. The caller must not free those pointers.
The drawback is that the life time of those strings is not predictable.
In the current Evolution libical, those same functions (not re
Chenthill wrote:
On Sat, 2008-09-06 at 11:02 +0200, Patrick Ohly wrote:
Hello!
http://sourceforge.net/projects/freeassociation/ has released 0.32 of
libical on 2008-09-01. The KDE-PIM team has switched to that code for
KDE 4.2.
On Sun, 2007-05-20 at 21:49 +, JP Rosevear wrote
On Mon, 2008-09-08 at 12:16 -0400, IGnatius T Foobar wrote:
> In what way does it break the userspace API? Is it possible that the
> API could be extended in such a way that memory handling depends upon
> how it's called?
Chenthill already provided the relevant links:
http://bugzilla.gnome.org/s
On Mon, 2008-09-08 at 12:16 -0400, IGnatius T Foobar wrote:
> Chenthill wrote:
> > On Sat, 2008-09-06 at 11:02 +0200, Patrick Ohly wrote:
> >
> > > Hello!
> > >
> > > http://sourceforge.net/projects/freeassociation/ has released 0.32 of
> > > libical on 2008-09-01. The KDE-PIM team has switche
On Sat, 2008-09-06 at 11:02 +0200, Patrick Ohly wrote:
> Hello!
>
> http://sourceforge.net/projects/freeassociation/ has released 0.32 of
> libical on 2008-09-01. The KDE-PIM team has switched to that code for
> KDE 4.2.
>
> On Sun, 2007-05-20 at 21:49 +, JP Rosevear wrote:
> > On Sun, 2007-0
Hello!
http://sourceforge.net/projects/freeassociation/ has released 0.32 of
libical on 2008-09-01. The KDE-PIM team has switched to that code for
KDE 4.2.
On Sun, 2007-05-20 at 21:49 +, JP Rosevear wrote:
> On Sun, 2007-05-20 at 15:03 +0100, Ross Burton wrote:
> > I discovered last week tha
On Sun, 2007-05-20 at 21:49 +, JP Rosevear wrote:
> On Sun, 2007-05-20 at 15:03 +0100, Ross Burton wrote:
> > Hi,
> >
> > I discovered last week that there is an attempt to resurrect libical
> > from non-maintainership, merge all of the patches from various forks,
> > and start making sane rel
On Sun, 2007-05-20 at 15:03 +0100, Ross Burton wrote:
> Hi,
>
> I discovered last week that there is an attempt to resurrect libical
> from non-maintainership, merge all of the patches from various forks,
> and start making sane releases again[1]. Are the evolution team as
> whole interested in m
On Sun, 2007-05-20 at 15:03 +0100, Ross Burton wrote:
> I'll happily start working on extracting the changes to EDS and pushing
> them into the new libical repository, if the Evolution team as a whole
> agrees that the fork of libical will be dropped.
+1
Matthew Barnes
__
Hi,
I discovered last week that there is an attempt to resurrect libical
from non-maintainership, merge all of the patches from various forks,
and start making sane releases again[1]. Are the evolution team as
whole interested in merging their changes to libical upstream and
depending on it to be
24 matches
Mail list logo
