You can subscribe to this list here.
| 2005 |
Jan
|
Feb
|
Mar
(9) |
Apr
(84) |
May
(18) |
Jun
(12) |
Jul
(6) |
Aug
(7) |
Sep
(10) |
Oct
(31) |
Nov
(59) |
Dec
(14) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2006 |
Jan
(53) |
Feb
(15) |
Mar
(43) |
Apr
(40) |
May
(63) |
Jun
(142) |
Jul
(54) |
Aug
(31) |
Sep
(30) |
Oct
(39) |
Nov
(36) |
Dec
(64) |
| 2007 |
Jan
(128) |
Feb
(261) |
Mar
(156) |
Apr
(127) |
May
(76) |
Jun
(131) |
Jul
(83) |
Aug
(124) |
Sep
(83) |
Oct
(88) |
Nov
(180) |
Dec
(90) |
| 2008 |
Jan
(86) |
Feb
(93) |
Mar
(117) |
Apr
(104) |
May
(65) |
Jun
(35) |
Jul
(38) |
Aug
(111) |
Sep
(58) |
Oct
(33) |
Nov
(102) |
Dec
(194) |
| 2009 |
Jan
(193) |
Feb
(74) |
Mar
(111) |
Apr
(77) |
May
(31) |
Jun
(20) |
Jul
(1) |
Aug
(3) |
Sep
(57) |
Oct
(125) |
Nov
(50) |
Dec
(3) |
| 2010 |
Jan
(26) |
Feb
(5) |
Mar
(13) |
Apr
(3) |
May
(3) |
Jun
(12) |
Jul
(27) |
Aug
(47) |
Sep
(105) |
Oct
(53) |
Nov
(34) |
Dec
(21) |
| 2011 |
Jan
(115) |
Feb
(17) |
Mar
|
Apr
(6) |
May
(16) |
Jun
(15) |
Jul
(85) |
Aug
(21) |
Sep
(13) |
Oct
(12) |
Nov
(28) |
Dec
(23) |
| 2012 |
Jan
|
Feb
(13) |
Mar
(4) |
Apr
|
May
(1) |
Jun
(5) |
Jul
(5) |
Aug
(31) |
Sep
(8) |
Oct
|
Nov
|
Dec
(1) |
| 2013 |
Jan
(1) |
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
(33) |
Sep
(9) |
Oct
(10) |
Nov
(2) |
Dec
|
| 2015 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(2) |
Dec
(4) |
| 2016 |
Jan
(2) |
Feb
|
Mar
(3) |
Apr
|
May
(3) |
Jun
|
Jul
|
Aug
|
Sep
(1) |
Oct
|
Nov
|
Dec
|
|
From: Christopher S. <cst...@su...> - 2010-11-22 14:42:36
|
Hi Quentin, Am Wednesday 10 November 2010 09:49:38 schrieb Quentin Denis: > Hi Christopher, > > nice to have updated packaeges for openSUSE. Just to know, how often do you > plan to update these packages? whenever it makes sense. I don't like daily updates because then you will often suffer from an inconsistent setup. Just ping me when you feel that the packages should be updated. I can also add you as a maintainer to the mobile:synchronization:UNSTABLE project. > Could you also provide kitchensync packages for kitchensync, please? I just > have released a working version: > http://kde-apps.org/content/show.php/KitchenSync?content=132538 Sorry, but I have no time for building and testing the kitchensync package atm. Feel free to build one in the buildservice and we can add it to the repo. Christopher -- SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nürnberg) Maxfeldstraße 5, 90409 Nürnberg, Germany |
|
From: Emanoil K. <del...@ya...> - 2010-11-20 16:48:52
|
Thanks for your attention
--- On Sat, 11/20/10, Michael Banck <mb...@gm...> wrote:
From: Michael Banck <mb...@gm...>
Subject: Re: [Opensync-devel] SyncML's sustainability
To: ope...@li...
Date: Saturday, November 20, 2010, 2:59 PM
On Tue, Nov 16, 2010 at 08:55:10PM +0100, Quentin Denis wrote:
> Emanoil Kotsev wrote:
> > I also doubt that it has been ported to 0.40. Does someone has used it
> > successfully?
> >
> > Also the responding on our question or the lack of such responses is
> > unacceptable if devs here want help.
> >
> > I guess you have to cc them so that they pay attention.
> >
> > ... Obviously people are not willing to sync with linux systems. Or it is
> > google conspiracy, so their sync would be preferred, to give them your
> > contacts, schedules etc for free. I'm wondering why we use encryption and
> > password protection then ... aaah yes, so that other users may not get
> > hands on it.
>
> Well, I put the two developers on cc, but guess what, both returned "Delivery
> Status Notification (Failure)" (on their @opensync.org address).
What did you expect? Armin hasn't worked on opensync for at least three
years.
I expect that someone answers our questions. I expect also that someone works on the code. I now understand why it sucks all those years and why I'm not able to sync without issues
I also expect you to remove the names (emails) of the people who have not been working more then a year or that do not answer mails. Also update the wiki page etc
I expect that someone cleans up the mess and boosts development. We jumped in because it said there is need but it seems that the core engine is broken and no one is working on it.
Michael has posted to this list last month, why didn't you use that
address?
Why ain't your reading the dev/user list ... why should we write to someone in person and why do I feel accused by you?
I expect that someone ansers to the user or dev group questions.
He seems to be willing to apply patches when people send them, but
probably doesn't have enough time currently to further development
himself.
Well probably I don't have the time either.
The support and documentation are really miserable. I expect you to improve it.
Don't be upset for what we are writing. Come up with solutions and answers that's what I expect.
I put many questions and no one answered. This is unacceptable. How can I make a patch this way.
Finally what do you expect from us? I'm not willing to reverse engineer the code someone has written and not fully documented. Also I did not like the syncml code - it looks ugly and it does not work. Someone has to fix it. ACtually this is all we need at the moment SOMEONE FIX THE SYNCML PLUGIN.
regards
|
|
From: deloptes <del...@ya...> - 2010-11-13 10:32:02
|
Quentin Denis wrote: > Is noone else responding to this thread? Is nobody else concerned with my > reported bug? Armin, Michael, how do you feel about the current syncml > plugin? I don't suggest to move to libsynthesis, but could libsyncml be at > least as capable then? > > As long as there is no fix for my issue, opensync is pretty useless for > me. I won't continue my contribution if I don't see in foreseeable future > a private use of opensync. > > The only alternative for me would be to use the depricated gnokii plugin > which is even not ported to 0.40. > > Sorry for putting some pressure but I am getting dubious about opensync's > development and capability to fix the bugs encountered by users. > > Kind regards, > Quentin > +1. I also doubt that it has been ported to 0.40. Does someone has used it successfully? Also the responding on our question or the lack of such responses is unacceptable if devs here want help. I guess you have to cc them so that they pay attention. ... Obviously people are not willing to sync with linux systems. Or it is google conspiracy, so their sync would be preferred, to give them your contacts, schedules etc for free. I'm wondering why we use encryption and password protection then ... aaah yes, so that other users may not get hands on it. |
|
From: Quentin D. <que...@gm...> - 2010-11-13 09:36:00
|
Is noone else responding to this thread? Is nobody else concerned with my reported bug? Armin, Michael, how do you feel about the current syncml plugin? I don't suggest to move to libsynthesis, but could libsyncml be at least as capable then? As long as there is no fix for my issue, opensync is pretty useless for me. I won't continue my contribution if I don't see in foreseeable future a private use of opensync. The only alternative for me would be to use the depricated gnokii plugin which is even not ported to 0.40. Sorry for putting some pressure but I am getting dubious about opensync's development and capability to fix the bugs encountered by users. Kind regards, Quentin > Quentin Denis wrote: > > > > > I am not involved in the development of the syncml plugin, nor am I able > > to contribute significantly, but aren't there worries of sustainability > > with the current framework? I am not suggesting to move to libsynthesis, > > but I would be interested in knowing how libsyncml will compete against > > the former. > > > > I also think this plugin is broken. :-) seems we were digging only at the > one end. > > osynctool --showgroup test4 > Group: test4 > Member 2: akonadi-sync > Member 1: syncml-http-client > > osynctool --configure test4 1 > /opt/testing/opensync/share/libopensync1/defaults/syncml-http-client:178: > element Name: Schemas validity error : Element 'Name': This element is not > expected. Expected is ( Enabled ). > /opt/testing/opensync/share/libopensync1/defaults/syncml-http-client:188: > element Name: Schemas validity error : Element 'Name': This element is not > expected. Expected is ( Enabled ). > /opt/testing/opensync/share/libopensync1/defaults/syncml-http-client:198: > element Name: Schemas validity error : Element 'Name': This element is not > expected. Expected is ( Enabled ). > ERROR: Plugin configuration file is not > valid! /opt/testing/opensync/share/libopensync1/schemas/plugin_config.xsd > EXIT_ERROR: osync_plugin_config_file_load: Plugin configuration file is not > valid! /opt/testing/opensync/share/libopensync1/schemas/plugin_config.xsd > EXIT_ERROR: osync_member_get_config_or_default: Plugin configuration file is > not > valid! /opt/testing/opensync/share/libopensync1/schemas/plugin_config.xsd > EXIT_ERROR: osynctool_configure_member: Plugin configuration file is not > valid! /opt/testing/opensync/share/libopensync1/schemas/plugin_config.xsd > > Error Summary: > ROOT CAUSE: "Plugin configuration file is not > valid! /opt/testing/opensync/share/libopensync1/schemas/plugin_config.xsd" |
|
From: Quentin D. <que...@gm...> - 2010-11-10 08:49:48
|
Hi Christopher, nice to have updated packaeges for openSUSE. Just to know, how often do you plan to update these packages? Could you also provide kitchensync packages for kitchensync, please? I just have released a working version: http://kde-apps.org/content/show.php/KitchenSync?content=132538 Kind regards, Quentin > Hi, > > just in case somebody is still using the old OpenSync:OpenSync-svn > buildservice repo, please switch to mobile:synchronization:UNSTABLE [1] to > get updated packages. > > [1]http://download.opensuse.org/repositories/mobile:/synchronization:/UNSTA > BLE/ > > Christopher > -- > SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nürnberg) > Maxfeldstraße 5, 90409 Nürnberg, Germany |
|
From: deloptes <del...@ya...> - 2010-11-09 21:09:30
|
Quentin Denis wrote: > > I am not involved in the development of the syncml plugin, nor am I able > to contribute significantly, but aren't there worries of sustainability > with the current framework? I am not suggesting to move to libsynthesis, > but I would be interested in knowing how libsyncml will compete against > the former. > I also think this plugin is broken. :-) seems we were digging only at the one end. osynctool --showgroup test4 Group: test4 Member 2: akonadi-sync Member 1: syncml-http-client osynctool --configure test4 1 /opt/testing/opensync/share/libopensync1/defaults/syncml-http-client:178: element Name: Schemas validity error : Element 'Name': This element is not expected. Expected is ( Enabled ). /opt/testing/opensync/share/libopensync1/defaults/syncml-http-client:188: element Name: Schemas validity error : Element 'Name': This element is not expected. Expected is ( Enabled ). /opt/testing/opensync/share/libopensync1/defaults/syncml-http-client:198: element Name: Schemas validity error : Element 'Name': This element is not expected. Expected is ( Enabled ). ERROR: Plugin configuration file is not valid! /opt/testing/opensync/share/libopensync1/schemas/plugin_config.xsd EXIT_ERROR: osync_plugin_config_file_load: Plugin configuration file is not valid! /opt/testing/opensync/share/libopensync1/schemas/plugin_config.xsd EXIT_ERROR: osync_member_get_config_or_default: Plugin configuration file is not valid! /opt/testing/opensync/share/libopensync1/schemas/plugin_config.xsd EXIT_ERROR: osynctool_configure_member: Plugin configuration file is not valid! /opt/testing/opensync/share/libopensync1/schemas/plugin_config.xsd Error Summary: ROOT CAUSE: "Plugin configuration file is not valid! /opt/testing/opensync/share/libopensync1/schemas/plugin_config.xsd" |
|
From: Christopher S. <cst...@su...> - 2010-11-09 15:12:59
|
Hi, just in case somebody is still using the old OpenSync:OpenSync-svn buildservice repo, please switch to mobile:synchronization:UNSTABLE [1] to get updated packages. [1]http://download.opensuse.org/repositories/mobile:/synchronization:/UNSTABLE/ Christopher -- SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nürnberg) Maxfeldstraße 5, 90409 Nürnberg, Germany |
|
From: Quentin D. <que...@gm...> - 2010-11-09 09:09:46
|
Hi guys, Some while ago I reported a critical issue with the syncml plugin which prevents me from committing changes to my phone. I have got no response to that issue, making opensync useless to me for now. http://www.opensync.org/ticket/1267 Along with these problems, I am wondering if the syncml plugin was not facing some fundamental troubles with the underlying libraries used. Aren't there critics that libsyncml is poorly performing in comparision to libsynthesis? I am not involved in the development of the syncml plugin, nor am I able to contribute significantly, but aren't there worries of sustainability with the current framework? I am not suggesting to move to libsynthesis, but I would be interested in knowing how libsyncml will compete against the former. At least as long as I am facing that critical bug I feel concerned about this open syncml question. Kind regards, Quentin |
|
From: deloptes <del...@ya...> - 2010-11-07 12:11:32
|
I need information about following
1. when do you call osync_data_set_objtype( )
2. do I need to call update_change in the example below
3. when I call
osync_change_set_data ( change, data );
where do I call
osync_data_unref ( data );
I'm trying this
osync_change_set_data ( change, data );
osync_data_unref ( data );
osync_context_report_change ( context(), change );
osync_change_unref ( change );
but I get i.e.
*** glibc detected *** osplugin: double free or corruption (out):
0x00007fff62bc41a0 ***
======= Backtrace: =========
/lib/libc.so.6(+0x71ad6)[0x7f4c57a26ad6]
/lib/libc.so.6(cfree+0x6c)[0x7f4c57a2b84c]
/opt/testing/opensync/lib/libopensync1/formats/vcard.so(+0xd69
[0x7f4c43b40d69]
/opt/testing/opensync/lib/libopensync.so.1(osync_data_unref+0x64
[0x7f4c5905f914]
/opt/testing/opensync/lib/libopensync.so.1(osync_change_unref+0x35
[0x7f4c5905f025]
/opt/testing/opensync/lib/libopensync1/plugins/akonadi-sync.so(+0xbaa0
[0x7f4c4f553aa0]
/opt/testing/opensync/lib/libopensync1/plugins/akonadi-sync.so(+0xc744
[0x7f4c4f554744]
/opt/testing/opensync/lib/libopensync1/plugins/akonadi-sync.so(+0xcae6
[0x7f4c4f554ae6]
/usr/lib/libQtCore.so.4(_ZN11QMetaObject8activateEP7QObjectPKS_iPPv+0x306
[0x7f4c4cfb02e6]
thanks in advance
regards
|
|
From: deloptes <del...@ya...> - 2010-11-07 12:03:29
|
Hi, can someone tell what is this about. The system seem to be working, but in syslog I see following Nov 7 13:00:36 lisa kernel: osplugin[9659]: segfault at 7f93fa08db60 ip 00007f93fa11a5a5 sp 00007fff94a13600 error 4 in libakonadi-kde.so.4.4. [7f93fa095000+1b1000] Nov 7 13:00:37 lisa kernel: osplugin[9664]: segfault at 7f95f5fd9b60 ip 00007f95f60665a5 sp 00007fff95de4360 error 4 in libakonadi-kde.so.4.4. [7f95f5fe1000+1b1000] Nov 7 13:00:50 lisa kernel: osplugin[9676]: segfault at 7faa58ae3b60 ip 00007faa58b705a5 sp 00007fffe8b6a2b0 error 4 in libakonadi-kde.so.4.4. [7faa58aeb000+1b1000] Nov 7 13:00:50 lisa kernel: osplugin[9681]: segfault at 7f742f52bb60 ip 00007f742f5b85a5 sp 00007fff7b18a710 error 4 in libakonadi-kde.so.4.4. [7f742f533000+1b1000] Nov 7 13:00:58 lisa kernel: osplugin[9693]: segfault at 7f102f3ecb60 ip 00007f102f4795a5 sp 00007fff98b37130 error 4 in libakonadi-kde.so.4.4. [7f102f3f4000+1b1000] Nov 7 13:00:58 lisa kernel: osplugin[9698]: segfault at 7f8ad04d4b60 ip 00007f8ad05615a5 sp 00007fff9f58a2b0 error 4 in libakonadi-kde.so.4.4. [7f8ad04dc000+1b1000] Nov 7 13:01:04 lisa kernel: osplugin[9709]: segfault at 7ff1d87b7b60 ip 00007ff1d88445a5 sp 00007fffb59c5770 error 4 in libakonadi-kde.so.4.4. [7ff1d87bf000+1b1000] Nov 7 13:01:04 lisa kernel: osplugin[9714]: segfault at 7f5c5d2dbb60 ip 00007f5c5d3685a5 sp 00007fff6e4acdd0 error 4 in libakonadi-kde.so.4.4. [7f5c5d2e3000+1b1000] |
|
From: Quentin D. <que...@gm...> - 2010-11-06 12:09:06
|
On Saturday 06 November 2010 02:39:05 opensync-devel- re...@li... wrote: > Date: Sat, 06 Nov 2010 02:38:38 +0100 > From: deloptes <del...@ya...> > Subject: Re: [Opensync-devel] kitchensync > To: ope...@li... > Message-ID: <ib2biu$849$1...@do...> > Content-Type: text/plain; charset=us-ascii > > Michael Banck wrote: > > > > > > If kitchensync is a seperate source tarball, that would mean getting > > fixes into Debian would be much easier, as a kdepim upload is a huge > > task. I wanted to get some of the Mandriva fixes into kitchensync for > > Debian lenny. but the KDE maintainers ignored them for kdepim, for > > example. > > I don't know who's maintaining it at the moment except Quentin, so he'll > probably have to say himself what is he situation with kitchensync. It took over kitchensync from KDE-playground where it has been abandoned. This makes me currently the only official maintainer, Tobias König (the author) having left the project. Kitchensync is currently: - maintained in the KDE SVN in the playground repo. It should be moved to "normal" kdepim as soon as it is bugfree. However, I am a bit scared of remaining the only responsible for this project since my coding experience (and free time) is moderate. If the Debian guys (and KDE PIM guys) are behind kitchensync, too, there should very soon be a move to normal svn. - present on kde-apps.org where the main public announcements are made. Users follow the development from there on. Release tarballs should also soon be available there. http://kde- apps.org/content/show.php/KitchenSync?content=132538 - in opensync's wiki. I want to make an office kitchensync home/webpage on opensync's wiki (easily created and managed). There were plans to integrate kitchesync into kontact, officially part of the kde pim. I think the code should be quite ready for this, too. > > One thing we might want to reconsider is on focusing on 0.40 as the next > > stable release. With 0.39 out a long time ago and a lot of fixes (and a > > working akonadi plugin, yay!), I think another development release > > should be made ASAP. > > AFAIK opensync was telling the same. this convinced me to work on > akonadi-sync I fully agree, I joined the team to make the next release happen ASAP, too. > > > > Now, how to version it? 0.39.1 looks weird. Three options: > > > > 1. Use 0.50 and aim for 0.60 as the next stable relase (a renamed 0.40). > > > > 2. Use 0.40 and just don't declare it stable, 1.0 will be the next > > stable release. > > > > 3. Use 0.40alpah1, 0.40alpha2, 0.40beta1, 0.40rc1 and so forth. > > > > Just saying "the next release will be 0.40, and it will be stable" is > > problematic, as that means hacking on trunk without much user feedback > > and a pressure to get it right and all bugs resolved which might take > > another couple of years. We should use clear big steps in versioning to reflect the higher activity in the development. I would suggest 0.50, 0.60, ... with minor bugfix releases inbetween (0.50.1). Please no endless alpha1,2,...beta1,... stories, this confuses our users and make them impatient. We should bear in mind that opensync has lost the biggest part of its userbase and that efforts should be made to get them back. So clear versioning should be made for them, not for developers' fun. > > Finally, let me reiterate something on the release: Either release the > > core opensync (and formats/bindings) first and announce a plugin relase > > a month (or so) later or let plugins catch up with the core release and > > release later (as the same version). Or even better, do both. > > the last option would be the best, but from my experience here I don't > think you can expect this (plugin to be considered stable with library) > better release core and then whatever plugin (as the same version). I agree with previous comments. However, is OpenSync's API not supposed to become stable once for all?? Then the plugins will be developed to enhance the features or to update to the latest peer API (ex google calendar), but not to have a constant catch-up competition with OpenSync's API. Since a good part of the plugins is now compatible with 0.40, I would suggest a opensync release (with format/bindings) jointly with a plugin pack that is ready for 0.40. > >> Again, I want to know what are the official plans for Opensync and > >> who's in charge with what. > > > > It's somewhat clear who is in charge of which plugin, but who has the > > say on release management is much less clear; it was Daniel Gollub for > > the last bunch of releases, but I am not sure he still steering the > > project to this end? > > > > > > I also have this impression but I'm quite new to this group. There should be clearer guidelines and roadmaps. Who is in charge of what? I even can't tell who is still actively contributing... kind regards, Quentin |
|
From: Harald J. <ha...@a-...> - 2010-11-06 11:17:38
|
On Sat, Nov 06, 2010 at 02:41:19AM +0100, deloptes wrote: > Harald Jenny wrote: > > >> > >> I'm not sure what decision was made about opensync. Opensync and plugins > >> should move accordingly. We are talking here about v0.40 > >> > >> And I guess that coordinating the whole thing with the responsible Debian > >> people before doing anything is a good idea. > >> > >> Again, I want to know what are the official plans for Opensync and who's > >> in charge with what. But yes, once opensync releases something officially > >> it would be then maintained by the debian/whatever-distro people - btw > >> they will be responsible for communicating problems to opensync debs > > > > Yes I have such pleasure myself ;-) > > > pleasure in what? Keeping up the communication between Debian users, other Debian developers and upstream people :-) (tends to partially consume more time than doing code development). > > > ------------------------------------------------------------------------------ > The Next 800 Companies to Lead America's Growth: New Video Whitepaper > David G. Thomson, author of the best-selling book "Blueprint to a > Billion" shares his insights and actions to help propel your > business during the next growth cycle. Listen Now! > http://p.sf.net/sfu/SAP-dev2dev > _______________________________________________ > Opensync-devel mailing list > Ope...@li... > https://lists.sourceforge.net/lists/listinfo/opensync-devel |
|
From: deloptes <del...@ya...> - 2010-11-06 01:45:16
|
Harald Jenny wrote: >> >> I'm not sure what decision was made about opensync. Opensync and plugins >> should move accordingly. We are talking here about v0.40 >> >> And I guess that coordinating the whole thing with the responsible Debian >> people before doing anything is a good idea. >> >> Again, I want to know what are the official plans for Opensync and who's >> in charge with what. But yes, once opensync releases something officially >> it would be then maintained by the debian/whatever-distro people - btw >> they will be responsible for communicating problems to opensync debs > > Yes I have such pleasure myself ;-) pleasure in what? |
|
From: deloptes <del...@ya...> - 2010-11-06 01:39:04
|
Michael Banck wrote: > > If kitchensync is a seperate source tarball, that would mean getting > fixes into Debian would be much easier, as a kdepim upload is a huge > task. I wanted to get some of the Mandriva fixes into kitchensync for > Debian lenny. but the KDE maintainers ignored them for kdepim, for > example. I don't know who's maintaining it at the moment except Quentin, so he'll probably have to say himself what is he situation with kitchensync. > >> I'm not sure what decision was made about opensync. Opensync and >> plugins should move accordingly. We are talking here about v0.40 > > One thing we might want to reconsider is on focusing on 0.40 as the next > stable release. With 0.39 out a long time ago and a lot of fixes (and a > working akonadi plugin, yay!), I think another development release > should be made ASAP. AFAIK opensync was telling the same. this convinced me to work on akonadi-sync > > Now, how to version it? 0.39.1 looks weird. Three options: > > 1. Use 0.50 and aim for 0.60 as the next stable relase (a renamed 0.40). > > 2. Use 0.40 and just don't declare it stable, 1.0 will be the next > stable release. > > 3. Use 0.40alpah1, 0.40alpha2, 0.40beta1, 0.40rc1 and so forth. > > Just saying "the next release will be 0.40, and it will be stable" is > problematic, as that means hacking on trunk without much user feedback > and a pressure to get it right and all bugs resolved which might take > another couple of years. my impression too > > Finally, let me reiterate something on the release: Either release the > core opensync (and formats/bindings) first and announce a plugin relase > a month (or so) later or let plugins catch up with the core release and > release later (as the same version). Or even better, do both. the last option would be the best, but from my experience here I don't think you can expect this (plugin to be considered stable with library) better release core and then whatever plugin (as the same version). > > This would make it easier for plugin authors to shift their focus > towards opensync when it's needed (i.e. when all the new APIs have to be > ported to). > >> And I guess that coordinating the whole thing with the responsible >> Debian people before doing anything is a good idea. > > Well, that is me for the most part, so should be doable. Thanks for knowing. I can not say anything about the plans of the opensync team. I just want to have a syncing solution when I move to kde4. > >> Again, I want to know what are the official plans for Opensync and >> who's in charge with what. > > It's somewhat clear who is in charge of which plugin, but who has the > say on release management is much less clear; it was Daniel Gollub for > the last bunch of releases, but I am not sure he still steering the > project to this end? > I also have this impression but I'm quite new to this group. |
|
From: Harald J. <ha...@a-...> - 2010-11-05 23:00:21
|
On Fri, Nov 05, 2010 at 04:10:30PM +0100, Michael Banck wrote: > Hi, Hello > > On Fri, Nov 05, 2010 at 07:53:31AM -0700, Emanoil Kotsev wrote: > > --- On Fri, 11/5/10, Harald Jenny <ha...@a-...> wrote:> > > > There were few discussions about the future of opensync and about > > > kitchensync as part of kde4. Quentin got kitchensync into kde-dev, > > > so if I'm not wrong it is in kde already, but somewhere in dev. > > > > So the main point should be to make them move it into normal kde again > > :-). > > If kitchensync is a seperate source tarball, that would mean getting > fixes into Debian would be much easier, as a kdepim upload is a huge > task. That's true but as opensync is a moving targets this will put much stress on a single maintainer... > I wanted to get some of the Mandriva fixes into kitchensync for > Debian lenny. but the KDE maintainers ignored them for kdepim, for > example. Hmmm that's not nice but maybe at this point the removal of kitchensync was already in the work. > > > I'm not sure what decision was made about opensync. Opensync and > > plugins should move accordingly. We are talking here about v0.40 > > One thing we might want to reconsider is on focusing on 0.40 as the next > stable release. With 0.39 out a long time ago and a lot of fixes (and a > working akonadi plugin, yay!), I think another development release > should be made ASAP. Sounds good > > Now, how to version it? 0.39.1 looks weird. Three options: > > 1. Use 0.50 and aim for 0.60 as the next stable relase (a renamed 0.40). > > 2. Use 0.40 and just don't declare it stable, 1.0 will be the next > stable release. > > 3. Use 0.40alpah1, 0.40alpha2, 0.40beta1, 0.40rc1 and so forth. Um... > > Just saying "the next release will be 0.40, and it will be stable" is > problematic, as that means hacking on trunk without much user feedback > and a pressure to get it right and all bugs resolved which might take > another couple of years. I guess the focus must be to have a somewhat working environment which wont change to much while bugs are being fixed. > > Finally, let me reiterate something on the release: Either release the > core opensync (and formats/bindings) first and announce a plugin relase > a month (or so) later or let plugins catch up with the core release and > release later (as the same version). Or even better, do both. Hmmm although the second one sounds better the former will more likely happen? > > This would make it easier for plugin authors to shift their focus > towards opensync when it's needed (i.e. when all the new APIs have to be > ported to). Agreed > > > And I guess that coordinating the whole thing with the responsible > > Debian people before doing anything is a good idea. > > Well, that is me for the most part, so should be doable. *ggg* good to hear, maybe with a good new Debian release I can find the time to look at the Motorola plugin. > > > Again, I want to know what are the official plans for Opensync and > > who's in charge with what. > > It's somewhat clear who is in charge of which plugin, but who has the > say on release management is much less clear; it was Daniel Gollub for > the last bunch of releases, but I am not sure he still steering the > project to this end? > > > Michael Kind regards Harald > > ------------------------------------------------------------------------------ > The Next 800 Companies to Lead America's Growth: New Video Whitepaper > David G. Thomson, author of the best-selling book "Blueprint to a > Billion" shares his insights and actions to help propel your > business during the next growth cycle. Listen Now! > http://p.sf.net/sfu/SAP-dev2dev > _______________________________________________ > Opensync-devel mailing list > Ope...@li... > https://lists.sourceforge.net/lists/listinfo/opensync-devel |
|
From: Harald J. <ha...@a-...> - 2010-11-05 22:52:13
|
On Fri, Nov 05, 2010 at 07:53:31AM -0700, Emanoil Kotsev wrote: > Hi, Hello > > --- On Fri, 11/5/10, Harald Jenny <ha...@a-...> wrote:> > > There were few discussions about the future of opensync and about kitchensync as part of kde4. Quentin got kitchensync into kde-dev, so if I'm not wrong it is in kde already, but somewhere in dev. > > So the main point should be to make them move it into normal kde again :-). > > Well, I just wanted to know what the group would say, but from my POV it is what I think is the best. However I would let Quentin handle KDE, as he already has contacts there. I guess it will move automatically as soon as it is usable Sounds good > > I'm not sure what decision was made about opensync. Opensync and plugins should move accordingly. We are talking here about v0.40 > > And I guess that coordinating the whole thing with the responsible Debian > people before doing anything is a good idea. > > Again, I want to know what are the official plans for Opensync and who's in charge with what. But yes, once opensync releases something officially it would be then maintained by the debian/whatever-distro people - btw they will be responsible for communicating problems to opensync debs Yes I have such pleasure myself ;-) > > regards Kind regards Harald > > > > > |
|
From: Michael B. <mb...@de...> - 2010-11-05 15:10:59
|
Hi, On Fri, Nov 05, 2010 at 07:53:31AM -0700, Emanoil Kotsev wrote: > --- On Fri, 11/5/10, Harald Jenny <ha...@a-...> wrote:> > > There were few discussions about the future of opensync and about > > kitchensync as part of kde4. Quentin got kitchensync into kde-dev, > > so if I'm not wrong it is in kde already, but somewhere in dev. > > So the main point should be to make them move it into normal kde again > :-). If kitchensync is a seperate source tarball, that would mean getting fixes into Debian would be much easier, as a kdepim upload is a huge task. I wanted to get some of the Mandriva fixes into kitchensync for Debian lenny. but the KDE maintainers ignored them for kdepim, for example. > I'm not sure what decision was made about opensync. Opensync and > plugins should move accordingly. We are talking here about v0.40 One thing we might want to reconsider is on focusing on 0.40 as the next stable release. With 0.39 out a long time ago and a lot of fixes (and a working akonadi plugin, yay!), I think another development release should be made ASAP. Now, how to version it? 0.39.1 looks weird. Three options: 1. Use 0.50 and aim for 0.60 as the next stable relase (a renamed 0.40). 2. Use 0.40 and just don't declare it stable, 1.0 will be the next stable release. 3. Use 0.40alpah1, 0.40alpha2, 0.40beta1, 0.40rc1 and so forth. Just saying "the next release will be 0.40, and it will be stable" is problematic, as that means hacking on trunk without much user feedback and a pressure to get it right and all bugs resolved which might take another couple of years. Finally, let me reiterate something on the release: Either release the core opensync (and formats/bindings) first and announce a plugin relase a month (or so) later or let plugins catch up with the core release and release later (as the same version). Or even better, do both. This would make it easier for plugin authors to shift their focus towards opensync when it's needed (i.e. when all the new APIs have to be ported to). > And I guess that coordinating the whole thing with the responsible > Debian people before doing anything is a good idea. Well, that is me for the most part, so should be doable. > Again, I want to know what are the official plans for Opensync and > who's in charge with what. It's somewhat clear who is in charge of which plugin, but who has the say on release management is much less clear; it was Daniel Gollub for the last bunch of releases, but I am not sure he still steering the project to this end? Michael |
|
From: Emanoil K. <del...@ya...> - 2010-11-05 14:53:38
|
Hi,
--- On Fri, 11/5/10, Harald Jenny <ha...@a-...> wrote:>
> There were few discussions about the future of opensync and about kitchensync as part of kde4. Quentin got kitchensync into kde-dev, so if I'm not wrong it is in kde already, but somewhere in dev.
So the main point should be to make them move it into normal kde again :-).
Well, I just wanted to know what the group would say, but from my POV it is what I think is the best. However I would let Quentin handle KDE, as he already has contacts there. I guess it will move automatically as soon as it is usable
I'm not sure what decision was made about opensync. Opensync and plugins should move accordingly. We are talking here about v0.40
And I guess that coordinating the whole thing with the responsible Debian
people before doing anything is a good idea.
Again, I want to know what are the official plans for Opensync and who's in charge with what. But yes, once opensync releases something officially it would be then maintained by the debian/whatever-distro people - btw they will be responsible for communicating problems to opensync debs
regards
|
|
From: Harald J. <ha...@a-...> - 2010-11-05 11:46:37
|
On Fri, Nov 05, 2010 at 04:31:06AM -0700, Emanoil Kotsev wrote: > Hi, Hi > > I don't see kitchensync there, I think the Debian KDE maintainers > > dropped it for KDE4 (if it is part of the kdepim package upstream) as it > > was unusable. > > There were few discussions about the future of opensync and about kitchensync as part of kde4. Quentin got kitchensync into kde-dev, so if I'm not wrong it is in kde already, but somewhere in dev. So the main point should be to make them move it into normal kde again :-). > > > Changelog says something like this yes, but I guess when you have a working > solution to incorporate into kdepim then chances that the software gets > accepted in Deian again are quite higher, not to mention the fact that then a > whole team and not you would be responsible for keeping it up-to-date. > > This is the primary goal. From my impression libopensync and some of the plugins are quite usable, so having them in one system like debian/ubuntu or whatever will bring us more testers and feedback. And I guess that coordinating the whole thing with the responsible Debian people before doing anything is a good idea. > > regards Kind regards Harald > > > > |
|
From: Emanoil K. <del...@ya...> - 2010-11-05 11:31:13
|
Hi,
> I don't see kitchensync there, I think the Debian KDE maintainers
> dropped it for KDE4 (if it is part of the kdepim package upstream) as it
> was unusable.
There were few discussions about the future of opensync and about kitchensync as part of kde4. Quentin got kitchensync into kde-dev, so if I'm not wrong it is in kde already, but somewhere in dev.
Changelog says something like this yes, but I guess when you have a working
solution to incorporate into kdepim then chances that the software gets
accepted in Deian again are quite higher, not to mention the fact that then a
whole team and not you would be responsible for keeping it up-to-date.
This is the primary goal. From my impression libopensync and some of the plugins are quite usable, so having them in one system like debian/ubuntu or whatever will bring us more testers and feedback.
regards
|
|
From: Harald J. <ha...@a-...> - 2010-11-05 11:12:42
|
On Fri, Nov 05, 2010 at 11:53:47AM +0100, Michael Banck wrote: > Hi, > > On Fri, Nov 05, 2010 at 10:48:36AM +0100, Harald Jenny wrote: > > On Fri, Nov 05, 2010 at 10:35:19AM +0100, Michael Banck wrote: > > > On Fri, Nov 05, 2010 at 01:18:03AM +0100, Harald Jenny wrote: > > > > On Thu, Nov 04, 2010 at 10:59:53PM +0100, deloptes wrote: > > > > > > > > > > I've fixed the member issue in kitchensync. Quentin will hopefully update > > > > > svn soon. I think it can be pushed to debian sid and other distros around > > > > > christmas, so that we may have testers of the whole environment. > > > > > > > > Sorry to interrupt but if kitchensync is already in Debian testing then it's > > > > not a good idea to upload a new version to Sid as this would prevent uploads > > > > fixing bugs to propagate to Squeeze (I guess the release team will not allow > > > > new versions to do this anymore). > > > > > > It is not in testing as far as I know. > > > > Please take a look at http://packages.debian.org/lenny/kitchensync and > > Lenny is stable, not testing and still at KDE3. Yes what I meant was that it was part of kdepim. > > > http://packages.qa.debian.org/k/kdepim.html. > > I don't see kitchensync there, I think the Debian KDE maintainers > dropped it for KDE4 (if it is part of the kdepim package upstream) as it > was unusable. Changelog says something like this yes, but I guess when you have a working solution to incorporate into kdepim then chances that the software gets accepted in Deian again are quite higher, not to mention the fact that then a whole team and not you would be responsible for keeping it up-to-date. > > > Michael Kind regards Harald > > ------------------------------------------------------------------------------ > The Next 800 Companies to Lead America's Growth: New Video Whitepaper > David G. Thomson, author of the best-selling book "Blueprint to a > Billion" shares his insights and actions to help propel your > business during the next growth cycle. Listen Now! > http://p.sf.net/sfu/SAP-dev2dev > _______________________________________________ > Opensync-devel mailing list > Ope...@li... > https://lists.sourceforge.net/lists/listinfo/opensync-devel |
|
From: Michael B. <mb...@de...> - 2010-11-05 10:54:02
|
Hi, On Fri, Nov 05, 2010 at 10:48:36AM +0100, Harald Jenny wrote: > On Fri, Nov 05, 2010 at 10:35:19AM +0100, Michael Banck wrote: > > On Fri, Nov 05, 2010 at 01:18:03AM +0100, Harald Jenny wrote: > > > On Thu, Nov 04, 2010 at 10:59:53PM +0100, deloptes wrote: > > > > > > > > I've fixed the member issue in kitchensync. Quentin will hopefully update > > > > svn soon. I think it can be pushed to debian sid and other distros around > > > > christmas, so that we may have testers of the whole environment. > > > > > > Sorry to interrupt but if kitchensync is already in Debian testing then it's > > > not a good idea to upload a new version to Sid as this would prevent uploads > > > fixing bugs to propagate to Squeeze (I guess the release team will not allow > > > new versions to do this anymore). > > > > It is not in testing as far as I know. > > Please take a look at http://packages.debian.org/lenny/kitchensync and Lenny is stable, not testing and still at KDE3. > http://packages.qa.debian.org/k/kdepim.html. I don't see kitchensync there, I think the Debian KDE maintainers dropped it for KDE4 (if it is part of the kdepim package upstream) as it was unusable. Michael |
|
From: Harald J. <ha...@a-...> - 2010-11-05 09:48:46
|
On Fri, Nov 05, 2010 at 10:35:19AM +0100, Michael Banck wrote: > On Fri, Nov 05, 2010 at 01:18:03AM +0100, Harald Jenny wrote: > > On Thu, Nov 04, 2010 at 10:59:53PM +0100, deloptes wrote: > > > > > > I've fixed the member issue in kitchensync. Quentin will hopefully update > > > svn soon. I think it can be pushed to debian sid and other distros around > > > christmas, so that we may have testers of the whole environment. > > > > Sorry to interrupt but if kitchensync is already in Debian testing then it's > > not a good idea to upload a new version to Sid as this would prevent uploads > > fixing bugs to propagate to Squeeze (I guess the release team will not allow > > new versions to do this anymore). > > It is not in testing as far as I know. Please take a look at http://packages.debian.org/lenny/kitchensync and http://packages.qa.debian.org/k/kdepim.html. Maybe you should contact one of the following persons before you do that: maint Debian Qt/KDE Maintainers, Sune Vuorela (u), Fathi Boudra (u), Armin Berres (u), Modestas Vainius (u), Michael Meskes (u) > > > Michael Kind regards Harald > > ------------------------------------------------------------------------------ > The Next 800 Companies to Lead America's Growth: New Video Whitepaper > David G. Thomson, author of the best-selling book "Blueprint to a > Billion" shares his insights and actions to help propel your > business during the next growth cycle. Listen Now! > http://p.sf.net/sfu/SAP-dev2dev > _______________________________________________ > Opensync-devel mailing list > Ope...@li... > https://lists.sourceforge.net/lists/listinfo/opensync-devel |
|
From: Michael B. <mb...@de...> - 2010-11-05 09:35:38
|
On Fri, Nov 05, 2010 at 01:18:03AM +0100, Harald Jenny wrote: > On Thu, Nov 04, 2010 at 10:59:53PM +0100, deloptes wrote: > > > > I've fixed the member issue in kitchensync. Quentin will hopefully update > > svn soon. I think it can be pushed to debian sid and other distros around > > christmas, so that we may have testers of the whole environment. > > Sorry to interrupt but if kitchensync is already in Debian testing then it's > not a good idea to upload a new version to Sid as this would prevent uploads > fixing bugs to propagate to Squeeze (I guess the release team will not allow > new versions to do this anymore). It is not in testing as far as I know. Michael |
|
From: Harald J. <ha...@a-...> - 2010-11-05 00:19:38
|
On Thu, Nov 04, 2010 at 10:59:53PM +0100, deloptes wrote: > > I've fixed the member issue in kitchensync. Quentin will hopefully update > svn soon. I think it can be pushed to debian sid and other distros around > christmas, so that we may have testers of the whole environment. Sorry to interrupt but if kitchensync is already in Debian testing then it's not a good idea to upload a new version to Sid as this would prevent uploads fixing bugs to propagate to Squeeze (I guess the release team will not allow new versions to do this anymore). > > What does the group think? > > I also don't want to carry the burden of taking design decisions but I need > a hint to solve the id/remoteId issue in akonadi-sync. > > regards Kind regards Harald Jenny > > > ------------------------------------------------------------------------------ > The Next 800 Companies to Lead America's Growth: New Video Whitepaper > David G. Thomson, author of the best-selling book "Blueprint to a > Billion" shares his insights and actions to help propel your > business during the next growth cycle. Listen Now! > http://p.sf.net/sfu/SAP-dev2dev > _______________________________________________ > Opensync-devel mailing list > Ope...@li... > https://lists.sourceforge.net/lists/listinfo/opensync-devel |