Re: Fwd: Status of opensync in Debian - mass removal very likely
Thanks to intrigeri for forwarding this message to me. There are
about 3 developers working on opensync, very part time, and I'm one of
them, and have taken the role of upstream maintainer for the library,
and some plugins as far as I am able. I lack test devices, so cannot
truly support all plugins.
Comments below...
On Sun, Mar 04, 2012 at 10:46:53AM +0100, intrigeri wrote:
> opensync/multisync is a complete mess, collecting 25 RC bugs between 20
> source packages and a collective 17,626 days waiting to enter testing.
> dd-list attached.
>
> Summary:
> libopensync-plugin-gnokii 1462 days old (needed 10 days) libopensync0 RC x 2
> libopensync-plugin-gpe 1462 days old (needed 10 days) libopensync0 RC x 2
> libopensync-plugin-irmc 976 days old (needed 10 days) libopensync0 RC
> libopensync-plugin-kdepim 1025 days old (needed 10 days) libopensync0 RC
> libopensync-plugin-moto 1207 days old (needed 10 days) libopensync0 RC x 2
> libopensync-plugin-opie 1190 days old (needed 10 days) libopensync0 RC x 2
> libopensync-plugin-palm 1461 days old (needed 10 days) libopensync0 RC x 2
> libopensync-plugin-python 1347 days old (needed 10 days) libopensync0 RC x 2
> libopensync-plugin-sunbird 1456 days old (needed 10 days) libopensync0 RC x 2
> multisync0.90 825 days old (needed 10 days) libopensync0 RC x 2
This is the 0.2x set of packages, I believe.
> osynctool 765 days old (needed 10 days) RC
> opensync 663 days old (needed 10 days) RC x 3
> libopensync-plugin-xmlformat 754 days old (needed 10 days) opensync
> libopensync-plugin-vformat 768 days old (needed 10 days) opensync
> libopensync-plugin-syncml 755 days old (needed 10 days) opensync
> libopensync-plugin-file 755 days old (needed 10 days) opensync
> libopensync-plugin-evolution2 755 days old (needed 10 days) libcamel-1.2-23 et al
> synce-sync-engine depends opensync, libopensync-plugin-python
> libopensync-plugin-google-calendar libopensync0 (experimental) RC x 3
> synce-kpm depends on synce-sync-engine
This are probably libopensync1exp7.
> Most depend on libopensync0 which does not exist anymore, those which
> have been updated are split between libopensync1exp3 and
> libopensync1exp7. libopensync1exp3 does not exist, libopensync1exp7 has
> 3 RC bugs.
The 0.2x version series is the only version of opensync that is
currently considered a stable release. As such, libopensync0 is the
library to include in Debian, if desired. I would discourage any use
of libopensync1exp3 or libopensync1exp7, as they are snapshots of the
0.3x development tree, and are ancient. There are a number of bugs
that have been fixed upstream in the 0.3x series.
> If there's no response (I'm NOT expecting fixes, just *some* idea of
> whether these RC bugs *can* be fixed and all the packages migrated to
> whatever counts as the latest available libopensync version), ALL of
> these packages will have to be removed. I'm afraid it's SO unlikely
> that anything is going to be truly fixed by Wheezy, the only real
> option for a deadline is 7 days to get *SOME* kind of expression of
> interest, some idea of a plan. Naturally, if the maintainers wish to
> file the removal bugs themselves, that would be appreciated.
I can't answer for the Debian maintainers, but I can give an update
on the upstream activity.
Upstream development is moving slowly from the SVN repos to git.
There is also a git repo that contains submodules of the libraries and
some plugins, called "binary-meta", which is intended to make creation of
binary packages easy (both RPM and deb). This has *nothing* to do with
Debian, and Debian will likely not like the approach that was taken,
but then again, I'm not sure if Debian wants opensync, as is. Version
0.4x is not ready, and the stable 0.22 is too brittle in some cases.
> I know all of these have already been removed from testing, but the
> packages in unstable are completely unusable / not installable. Just
> leaving RC bugs in unstable for years should not be acceptable.
I can sense the frustration, and I share it somewhat, but there is little
that a project can do, if it is large, and has a lack of developers
and a lack of test devices. As such, I can understand if opensync
disappears from Debian. I plan to release binary packages for opensync
users anyway, so those users shouldn't have to rely on Debian. Having
outdated packages in Debian hurts Debian and Opensync.
> There are packages in experimental too but those appear to be gathering RC
> bugs as well, so I'll also file removal bugs for those.
Fully agreed on that. Development versions in the 0.3x series should not
be included, unless someone is dedicated to uploading current snapshots
of the git trees into experimental only.
Thanks for addressing this.
I would appreciate staying in the CC list for this thread.
- Chris
Reply to: