12:47 p.m.
Hi Patrick,
I'm looking for the reason why syncevolution 1.3 requires libsynthesis
3.4.0.16.8. I'm not shure what to look for. Could you point me to
specific commits in syncevolution? The dependency change in
configure.ac came in with a commit that also added a lot of stuff to
the NEWS file.
Regards,
Tino
1:15 p.m.
On Mon, 2012-11-26 at 13:47 +0100, tino.keitel+syncevolution(a)tikei.de
wrote:
I'm looking for the reason why syncevolution 1.3 requires
libsynthesis
3.4.0.16.8. I'm not shure what to look for. Could you point me to
specific commits in syncevolution? The dependency change in
configure.ac came in with a commit that also added a lot of stuff to
the NEWS file.
In that commit I was just cleaning up for the release. The actual
changes were there before.
Have a look at the commit messages in libsynthesis where I bump the
version. That together with the libsynthesis patches gives an idea why
the new version is needed for SyncEvolution:
$ git log
libsynthesis_3.4.0.16+syncevolution-1-2-99-1..libsynthesis_3.4.0.16+syncevolution-1-3-1
commit 99159e0991664f8c8319e634598ea6c9bd73fcc2
Author: Patrick Ohly <patrick.ohly(a)intel.com>
Date: Mon Sep 10 09:15:20 2012 +0200
autotools: bumped minor version
Bumped minor version so that SyncEvolution can ensure that the version
it is compiled against really fixes the VJOURNAL<->plain text
conversion problem. ^^^^^^^^^^^^^^^^^^^^^
^^^^^^^^^^^^^^^^^^^
A fix required for 1.3.1.
commit 0a4a64f976a0f1812c9011efe7d832e381889e97
Author: Patrick Ohly <patrick.ohly(a)intel.com>
Date: Thu Aug 16 18:59:22 2012 +0200
engine: allow text->VJOURNAL conversion
SyncEvolution uses the Synthesis engine to convert a plain text memo
to iCalendar 2.0 in the local storage. ...
And here's the feature itself, added earlier.
The other commits are about build issues (pthread) and memory handling
(reading uninitialized memory). Those are not essential for
SyncEvolution, but useful anyway.
--
Best Regards, Patrick Ohly
The content of this message is my personal opinion only and although
I am an employee of Intel, the statements I make here in no way
represent Intel's position on the issue, nor am I authorized to speak
on behalf of Intel on this matter.
1:17 p.m.
On Mon, 2012-11-26 at 13:47 +0100, tino.keitel+syncevolution(a)tikei.de
wrote:
I'm looking for the reason why syncevolution 1.3 requires
libsynthesis
3.4.0.16.8. I'm not shure what to look for. Could you point me to
specific commits in syncevolution? The dependency change in
configure.ac came in with a commit that also added a lot of stuff to
the NEWS file.
In that commit I was just cleaning up for the release. The actual
changes were there before.
Have a look at the commit messages in libsynthesis where I bump the
version. That together with the libsynthesis patches gives an idea why
the new version is needed for SyncEvolution:
$ git log
libsynthesis_3.4.0.16+syncevolution-1-2-99-1..libsynthesis_3.4.0.16+syncevolution-1-3-1
commit 99159e0991664f8c8319e634598ea6c9bd73fcc2
Author: Patrick Ohly <patrick.ohly(a)intel.com>
Date: Mon Sep 10 09:15:20 2012 +0200
autotools: bumped minor version
Bumped minor version so that SyncEvolution can ensure that the version
it is compiled against really fixes the VJOURNAL<->plain text
conversion problem. ^^^^^^^^^^^^^^^^^^^^^
^^^^^^^^^^^^^^^^^^^
A fix required for 1.3, which introduces the VJOURNAL<->plain feature
(part of WebDAV: support tasks and memos (BMC #24893)).
commit 0a4a64f976a0f1812c9011efe7d832e381889e97
Author: Patrick Ohly <patrick.ohly(a)intel.com>
Date: Thu Aug 16 18:59:22 2012 +0200
engine: allow text->VJOURNAL conversion
SyncEvolution uses the Synthesis engine to convert a plain text memo
to iCalendar 2.0 in the local storage. ...
And here's the feature itself, added earlier.
The other commits are about build issues (pthread) and memory handling
(reading uninitialized memory). Those are not essential for
SyncEvolution, but useful anyway.
--
Best Regards, Patrick Ohly
The content of this message is my personal opinion only and although
I am an employee of Intel, the statements I make here in no way
represent Intel's position on the issue, nor am I authorized to speak
on behalf of Intel on this matter.
1:30 p.m.
On Mon, Nov 26, 2012 at 14:17:27 +0100, Patrick Ohly wrote:
On Mon, 2012-11-26 at 13:47 +0100,
tino.keitel+syncevolution(a)tikei.de
wrote:
> I'm looking for the reason why syncevolution 1.3 requires libsynthesis
> 3.4.0.16.8. I'm not shure what to look for. Could you point me to
> specific commits in syncevolution? The dependency change in
> configure.ac came in with a commit that also added a lot of stuff to
> the NEWS file.
In that commit I was just cleaning up for the release. The actual
changes were there before.
Have a look at the commit messages in libsynthesis where I bump the
version. That together with the libsynthesis patches gives an idea why
the new version is needed for SyncEvolution:
$ git log
libsynthesis_3.4.0.16+syncevolution-1-2-99-1..libsynthesis_3.4.0.16+syncevolution-1-3-1
commit 99159e0991664f8c8319e634598ea6c9bd73fcc2
Author: Patrick Ohly <patrick.ohly(a)intel.com>
Date: Mon Sep 10 09:15:20 2012 +0200
autotools: bumped minor version
Bumped minor version so that SyncEvolution can ensure that the version
it is compiled against really fixes the VJOURNAL<->plain text
conversion problem. ^^^^^^^^^^^^^^^^^^^^^
^^^^^^^^^^^^^^^^^^^
A fix required for 1.3, which introduces the VJOURNAL<->plain feature
(part of WebDAV: support tasks and memos (BMC #24893)).
commit 0a4a64f976a0f1812c9011efe7d832e381889e97
Author: Patrick Ohly <patrick.ohly(a)intel.com>
Date: Thu Aug 16 18:59:22 2012 +0200
engine: allow text->VJOURNAL conversion
SyncEvolution uses the Synthesis engine to convert a plain text memo
to iCalendar 2.0 in the local storage. ...
Hi,
I noticed that. I was merely interested in specific _syncevolution_
commits that require this. I could not find any relevant syncevolution
commits in the timeframe of the above commit.
Background: I'm preparing a new upload for Debian that is based on
1.2.99.1 and fixes for important bugs. I decided to not package 1.3.x
for Debian Wheezy, as the freeze policy is too strict meanwhile.
Regards,
Tino
1:56 p.m.
On Mon, 2012-11-26 at 14:30 +0100, tino.keitel+syncevolution(a)tikei.de
wrote:
On Mon, Nov 26, 2012 at 14:17:27 +0100, Patrick Ohly wrote:
> On Mon, 2012-11-26 at 13:47 +0100, tino.keitel+syncevolution(a)tikei.de
> wrote:
> > I'm looking for the reason why syncevolution 1.3 requires libsynthesis
> > 3.4.0.16.8. I'm not shure what to look for. Could you point me to
> > specific commits in syncevolution? The dependency change in
> > configure.ac came in with a commit that also added a lot of stuff to
> > the NEWS file.
>
> In that commit I was just cleaning up for the release. The actual
> changes were there before.
>
> Have a look at the commit messages in libsynthesis where I bump the
> version. That together with the libsynthesis patches gives an idea why
> the new version is needed for SyncEvolution:
>
> $ git log
libsynthesis_3.4.0.16+syncevolution-1-2-99-1..libsynthesis_3.4.0.16+syncevolution-1-3-1
> commit 99159e0991664f8c8319e634598ea6c9bd73fcc2
> Author: Patrick Ohly <patrick.ohly(a)intel.com>
> Date: Mon Sep 10 09:15:20 2012 +0200
>
> autotools: bumped minor version
>
> Bumped minor version so that SyncEvolution can ensure that the version
> it is compiled against really fixes the VJOURNAL<->plain text
> conversion problem. ^^^^^^^^^^^^^^^^^^^^^
> ^^^^^^^^^^^^^^^^^^^
>
> A fix required for 1.3, which introduces the VJOURNAL<->plain feature
> (part of WebDAV: support tasks and memos (BMC #24893)).
>
> commit 0a4a64f976a0f1812c9011efe7d832e381889e97
> Author: Patrick Ohly <patrick.ohly(a)intel.com>
> Date: Thu Aug 16 18:59:22 2012 +0200
>
> engine: allow text->VJOURNAL conversion
>
> SyncEvolution uses the Synthesis engine to convert a plain text memo
> to iCalendar 2.0 in the local storage. ...
>
Hi,
I noticed that. I was merely interested in specific _syncevolution_
commits that require this. I could not find any relevant syncevolution
commits in the timeframe of the above commit.
Background: I'm preparing a new upload for Debian that is based on
1.2.99.1 and fixes for important bugs. I decided to not package 1.3.x
for Debian Wheezy, as the freeze policy is too strict meanwhile.
It's the memo support in WebDAV which uses the VJOURNAL<->plain
conversion. Search for VJOURNAL and/or "text" in the SyncEvolution
commit messages.
For example:
commit 7ce9b7ff258565a2ecab8e344d86ef9497ba57ce
Author: Patrick Ohly <patrick.ohly(a)intel.com>
Date: Mon Jun 18 16:04:51 2012 +0200
WebDAV: improved VJOURNAL -> plain/text conversion
When a memo in VJOURNAL format from the CalDAV backend gets converted
to plain text *and* the description starts with summary plus newline,
then only the description is used in the plain text version, to avoid
duplicating the summary.
Such entries are produced by SyncEvolution when importing plain text
into EDS. The conversion in the CalDAV backend uses a slightly
different logic and strips the first line from the incoming text
instead of just copying it.
The main reason for this change is that the new mechanism (based
libsynthesis text profile) makes it easier to implement the conversion
that way.
I can't give you a list of commits which need to be back-ported. That
would be akin to maintaining a stable branch based on 1.2.99.1. I don't
have the time for that. I also doubt that the result will be really
better than 1.3.2. This kind of back-porting comes with its own risks.
Basically you are releasing a version which has not seen any kind of
testing outside of Debian. Good luck ;-}
--
Best Regards, Patrick Ohly
The content of this message is my personal opinion only and although
I am an employee of Intel, the statements I make here in no way
represent Intel's position on the issue, nor am I authorized to speak
on behalf of Intel on this matter.
1:57 p.m.
On Mon, 2012-11-26 at 14:56 +0100, Patrick Ohly wrote:
On Mon, 2012-11-26 at 14:30 +0100,
tino.keitel+syncevolution(a)tikei.de
wrote:
> On Mon, Nov 26, 2012 at 14:17:27 +0100, Patrick Ohly wrote:
> > On Mon, 2012-11-26 at 13:47 +0100, tino.keitel+syncevolution(a)tikei.de
> > wrote:
> > > I'm looking for the reason why syncevolution 1.3 requires
libsynthesis
> > > 3.4.0.16.8. I'm not shure what to look for. Could you point me to
> > > specific commits in syncevolution? The dependency change in
> > > configure.ac came in with a commit that also added a lot of stuff to
> > > the NEWS file.
> >
> > In that commit I was just cleaning up for the release. The actual
> > changes were there before.
> >
> > Have a look at the commit messages in libsynthesis where I bump the
> > version. That together with the libsynthesis patches gives an idea why
> > the new version is needed for SyncEvolution:
> >
> > $ git log
libsynthesis_3.4.0.16+syncevolution-1-2-99-1..libsynthesis_3.4.0.16+syncevolution-1-3-1
> > commit 99159e0991664f8c8319e634598ea6c9bd73fcc2
> > Author: Patrick Ohly <patrick.ohly(a)intel.com>
> > Date: Mon Sep 10 09:15:20 2012 +0200
> >
> > autotools: bumped minor version
> >
> > Bumped minor version so that SyncEvolution can ensure that the version
> > it is compiled against really fixes the VJOURNAL<->plain text
> > conversion problem. ^^^^^^^^^^^^^^^^^^^^^
> > ^^^^^^^^^^^^^^^^^^^
> >
> > A fix required for 1.3, which introduces the VJOURNAL<->plain feature
> > (part of WebDAV: support tasks and memos (BMC #24893)).
> >
> > commit 0a4a64f976a0f1812c9011efe7d832e381889e97
> > Author: Patrick Ohly <patrick.ohly(a)intel.com>
> > Date: Thu Aug 16 18:59:22 2012 +0200
> >
> > engine: allow text->VJOURNAL conversion
> >
> > SyncEvolution uses the Synthesis engine to convert a plain text memo
> > to iCalendar 2.0 in the local storage. ...
> >
>
> Hi,
>
> I noticed that. I was merely interested in specific _syncevolution_
> commits that require this. I could not find any relevant syncevolution
> commits in the timeframe of the above commit.
>
> Background: I'm preparing a new upload for Debian that is based on
> 1.2.99.1 and fixes for important bugs. I decided to not package 1.3.x
> for Debian Wheezy, as the freeze policy is too strict meanwhile.
It's the memo support in WebDAV which uses the VJOURNAL<->plain
conversion. Search for VJOURNAL and/or "text" in the SyncEvolution
commit messages.
For example:
commit 7ce9b7ff258565a2ecab8e344d86ef9497ba57ce
Author: Patrick Ohly <patrick.ohly(a)intel.com>
Date: Mon Jun 18 16:04:51 2012 +0200
WebDAV: improved VJOURNAL -> plain/text conversion
When a memo in VJOURNAL format from the CalDAV backend gets converted
to plain text *and* the description starts with summary plus newline,
then only the description is used in the plain text version, to avoid
duplicating the summary.
Such entries are produced by SyncEvolution when importing plain text
into EDS. The conversion in the CalDAV backend uses a slightly
different logic and strips the first line from the incoming text
instead of just copying it.
The main reason for this change is that the new mechanism (based
libsynthesis text profile) makes it easier to implement the conversion
that way.
Here are some more (probably the main ones):
commit 16e0b4af191fda9c4d2a8f981d5c2513fb818d11
Author: Patrick Ohly <patrick.ohly(a)intel.com>
Date: Fri Jun 15 12:09:07 2012 +0200
WebDAV: exchange VJOURNAL as iCalendar 2.0 or plain text
Use the new "text/calendar+plain" type so that "caldavjournal" can
be
used with peers which do not support iCalendar 2.0 for memos.
commit 92d7e7cc489b7251a122bf2b1eccec3fab6f576c
Author: Patrick Ohly <patrick.ohly(a)intel.com>
Date: Fri Jun 15 12:07:46 2012 +0200
engine: support VJOURNAL and VJOURNAL+text/plain
The "text/calendar" type now also contains rules for parsing and
generating VJOURNAL in iCalendar 2.0 and vCalendar 1.0. When using
"text/calendar+plain", the internal format is iCalendar 2.0 with plain
text used as alternative if the sync peer does not support VJOURNAL
for memos.
These types can be used as "databaseFormat" of the file backend and by
other backends which want to replace plain text as exchange format for
memos.
The file backend can also use "text/calendar+plain", so this is not just
for WebDAV.
--
Best Regards, Patrick Ohly
The content of this message is my personal opinion only and although
I am an employee of Intel, the statements I make here in no way
represent Intel's position on the issue, nor am I authorized to speak
on behalf of Intel on this matter.
2:12 p.m.
On Mon, Nov 26, 2012 at 14:56:03 +0100, Patrick Ohly wrote:
[...]
I can't give you a list of commits which need to be back-ported.
That
would be akin to maintaining a stable branch based on 1.2.99.1. I don't
have the time for that.
Hi Patrick,
of cause, I'm aware that I'm on my own here.
I also doubt that the result will be really
better than 1.3.2.
I think it's better than releasing Wheezy with 1.2.99.1, which has
broken sync-ui, broken autosync etc.
This kind of back-porting comes with its own risks.
I'm fully aware of that.
Basically you are releasing a version which has not seen any kind of
testing outside of Debian. Good luck ;-}
My intention is to provide backports of 1.3.x once Wheezy is released
via backports.debian.org and point users to the backport if necessary.
Thanks for the pointers to the commits.
Regards,
Tino
3:47 p.m.
Hi Tino,
I don't know the details of Debian's freeze policy, but it seems to me
that you have a very strong argument for getting 1.3.x into Wheezy: With
very high probability, 1.3.x is going to be more stable and more useful
than 1.2.99.1 or a 1.2.99.x with fixes and backported features.
Version numbers mean nothing in and of themselves. In this case,
upgrading to a more recent version seems to be a much more reasonable
fix than backporting fixes (or even fixing from scratch).
Justus
tino.keitel+syncevolution(a)tikei.de wrote on Mon, 26 Nov 2012 15:12:36
+0100:
On Mon, Nov 26, 2012 at 14:56:03 +0100, Patrick Ohly wrote:
> This kind of back-porting comes with its own risks.
I'm fully aware of that.
> Basically you are releasing a version which has not seen any kind of
> testing outside of Debian. Good luck ;-}
Or even within Debian...
My intention is to provide backports of 1.3.x once Wheezy is
released
via backports.debian.org and point users to the backport if necessary.
7:16 a.m.
On Mon, Nov 26, 2012 at 16:47:33 +0100, Justus-bulk(a)Piater.name wrote:
Hi Tino,
I don't know the details of Debian's freeze policy, but it seems to me
that you have a very strong argument for getting 1.3.x into Wheezy: With
very high probability, 1.3.x is going to be more stable and more useful
than 1.2.99.1 or a 1.2.99.x with fixes and backported features.
Here are the details:
http://release.debian.org/wheezy/freeze_policy.html
Just throwing in a new upstream version with a rather large diff
"because it's better than the old version" just is not an option.
Regards,
Tino
3459
days inactive
3460
days old
syncevolution@synevolution.org
8 comments
4 participants
participants (4)
-
Justus-bulk＠Piater.name -
Patrick Ohly -
Tino Keitel -
tino.keitel+syncevolution＠tikei.de