[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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: