Should we officially kill the 0.22 ?

[Adam Williamson-4]

On Fri, 2009-03-27 at 19:52 +0200, Juha Tuomala wrote:

> I didn't refer that nonsense about me suggesting to keep the 0.3x and
> libsyncml stuff, don't know where those came but everyone here knows
> what I think. :-D

>
> All i tried to say, that ship what works and is supported: wbxml &
> libsyncml

But what's the point? They don't *do* anything without opensync. What
use is it having packages for current versions of these in a
distribution if you can't do anything with them? Who does that help?

As I wrote, if you provide some kind of application which does something
useful with them, then I'm happy to support getting them into Fedora;
it's perfectly possible for us to ship both old versions for opensync
0.22 and newer versions for something else in parallel.

If we can ship a current / fixed wbxml2 and it will still work with
libsyncml 0.4.6 and opensync 0.22 I'd be happy with that, too, btw. I
don't know the details of this issue.

But, I'm sorry, proposing we should drop opensync entirely just because
you think people using 0.22 will somehow hamper upstream development is
crazy. If upstream wants to work on 0.3/0.4 and not be bothered about
0.22 - fine. Close bugs filed on 0.22 and don't reply to messages from
people using it, or just send a stock reply telling them to talk to the
Fedora maintainers. That's OK, go ahead and do that, I don't mind at
all. But the fact is that 0.22 can do useful stuff for a lot of people
and devices, so shipping it provides valuable functionality to Fedora.
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org
http://www.happyassassin.net


------------------------------------------------------------------------------
_______________________________________________
Opensync-devel mailing list
Opensync-devel@...
https://lists.sourceforge.net/lists/listinfo/opensync-devel

[Daniel Gollub-2]

On Friday 27 March 2009 06:50:21 pm Michael Banck wrote:
> > I haven't seen much patches from distributions to fix actually real
> > functional bugs inside 0.3x.
>
> The reason is probably similar to what Michael Bell and Patrick Ohly
> wrote - if even plugin developers cannot constructively contribute code
> because the core is either too complex or moving too fast, the same is
> probably true for the distribution maintainers (or anybody else I
> guess).

JFYI, i started with gnokii-sync plugin ;) So actually i used to be a plugin
developer as well. I guess thats the case for most people stepping into
OpenSync core development. Graham (gpe-sync) rewrote the timeout handling,
Björn (tomboy-sync) is cleaning up the API and looked into areas like
conversion path, Ian and parahl both worked in the beginning on evo2-sync and
did also major clean ups in the testsuite or inside the core (fixing testsuite
is even more tricky then doing "just" core things), Paul (opie-sync) ... and
for sure many more i forgot.

So it's not impossible...
Yes, we're locking API documentation, Design guides and many more. But most of
us didn't implemented entire components - we actually all do mostly bug fixing
and actually getting things working.

>
> > The problem i'm  also seeing is: shipping experimental release like
> > 0.3x just interrupts the trunk development.
>
> However, they also represent a defined meta-frozen API in time,
> something plugin developers can potentionally look at as "this revision
> is probably rather stable compared to any other random revision, so is a
> good starting point for me porting my plugin to".  Otherwise, plugin
> developers will have to look at trunk when they have some time to tend
> to their plugin, and in the (not unlikely) case that trunk is currently
> undergoing some API transition, they will lose time getting up to speed,
> maybe.
>
> But anyway, the above point is hopefull moot now that opensync is
> converging towards a stable API.

Actually in meanwhile my impression is that telling plugin developers that the
best thing to do when writing a new plugin is to develop it against trunk was
wrong. I guess everyone got frustrated by the fast moving target...

I guess we all learned a lot - and something like a 0.3x development cycle is
a very bad thing if you're understaffed. But keeping going with 0.2x and in
parallel developing 0.3x wasn't sane option 2 years ago when i released 0.30.

Remember the former "dev-branch" was redesigned/rewritten by one person -
which is no longer active. But at this time the code solved major problems...
(maybe someone remembers the "objtype filtering" from 0.22 times)

>
> > - announcing 0.22 EO* before 0.40 gets for sure misunderstood at some
> > point (people can't read!) - If stable distros package 0.3x (with or
> > without communication to the user) it will slow down our current
> > development - I support only two OpenSync releases: trunk and 0.22
>
> I agree, I don't see any point in making a statement about 0.22 right
> now.  There should be a statement when the opensync maintainers consider
> a 0.3x/0.4x release "mostly as good as 0.22", though I guess.

For 0.39 there are 3 tickets left. And a decision how the capabilities has to
look like. Later one is still up to me ... i just need time to write a design
summary about the capabilities thing.

best regards,
Daniel

------------------------------------------------------------------------------
_______________________________________________
Opensync-devel mailing list
Opensync-devel@...
https://lists.sourceforge.net/lists/listinfo/opensync-devel

[Daniel Gollub-2]

On Friday 27 March 2009 07:07:52 pm Adam Williamson wrote:

> On Fri, 2009-03-27 at 19:52 +0200, Juha Tuomala wrote:
> > I didn't refer that nonsense about me suggesting to keep the 0.3x and
> > libsyncml stuff, don't know where those came but everyone here knows
> > what I think. :-D
> >
> >
> > All i tried to say, that ship what works and is supported: wbxml &
> > libsyncml
>
> But what's the point? They don't do anything without opensync. What
> use is it having packages for current versions of these in a
> distribution if you can't do anything with them? Who does that help?

>
> As I wrote, if you provide some kind of application which does something
> useful with them, then I'm happy to support getting them into Fedora;
> it's perfectly possible for us to ship both old versions for opensync
> 0.22 and newer versions for something else in parallel.

libsyncml brings syncml-ds-tool - which could be useful for _advanced_ users.

My personal feeling is that 80% of the users would be satisfied if they just
could "backup" and "restore" contacts. E.g. when switching to a different
phone.

But please check back with Michael Bell if he wants to have big PR about this
tool.

>
> If we can ship a current / fixed wbxml2 and it will still work with
> libsyncml 0.4.6 and opensync 0.22 I'd be happy with that, too, btw. I
> don't know the details of this issue.

Why not ship two version of libsyncml? The shared libraries should have
differnet so-names ... not quite sure how hard this would be to package.

Ship libsymcl which is known to work with opensync 0.22.
And latest stable relase of libsyncml with syncml-ds-tool packaged.

>
> But, I'm sorry, proposing we should drop opensync entirely just because
> you think people using 0.22 will somehow hamper upstream development is
> crazy. If upstream wants to work on 0.3/0.4 and not be bothered about
> 0.22 - fine. Close bugs filed on 0.22 and don't reply to messages from
> people using it, or just send a stock reply telling them to talk to the
> Fedora maintainers. That's OK, go ahead and do that, I don't mind at
> all. But the fact is that 0.22 can do useful stuff for a lot of people
> and devices, so shipping it provides valuable functionality to Fedora.

I agree here - i know many people having working 0.22. That's why I'm
supporting 0.22. It doesn't have high priority as the trunk development but if
someone contacts me with a serious functional issue i would look into that
problem.

And for that reason i don't want to communicate 0.22 as dead - since i fear
this would end up that someone is going to package 0.38 ;)

Best Regards,
Daniel

------------------------------------------------------------------------------
_______________________________________________
Opensync-devel mailing list
Opensync-devel@...
https://lists.sourceforge.net/lists/listinfo/opensync-devel

[Adam Williamson-4]

On Fri, 2009-03-27 at 19:31 +0100, Daniel Gollub wrote:

> > > All i tried to say, that ship what works and is supported: wbxml &
> > > libsyncml
> >
> > But what's the point? They don't do anything without opensync. What
> > use is it having packages for current versions of these in a
> > distribution if you can't do anything with them? Who does that help?
>
> >
> > As I wrote, if you provide some kind of application which does something
> > useful with them, then I'm happy to support getting them into Fedora;
> > it's perfectly possible for us to ship both old versions for opensync
> > 0.22 and newer versions for something else in parallel.
>
> libsyncml brings syncml-ds-tool - which could be useful for _advanced_ users.
>
> My personal feeling is that 80% of the users would be satisfied if they just
> could "backup" and "restore" contacts. E.g. when switching to a different
> phone.

You can do that with the gnokii plugin =)

> But please check back with Michael Bell if he wants to have big PR about this
> tool.

OK. Thanks for the info. Michael? Do you think it's a good idea for
distros to ship a current libsyncml package specifically to allow people
to use syncml-ds-tool?

> > If we can ship a current / fixed wbxml2 and it will still work with
> > libsyncml 0.4.6 and opensync 0.22 I'd be happy with that, too, btw. I
> > don't know the details of this issue.
>
> Why not ship two version of libsyncml? The shared libraries should have
> differnet so-names ... not quite sure how hard this would be to package.

That was what I was proposing a paragraph earlier (cut from your quote)
- it's perfectly possible, yes. That's one of the benefits of the
library major system. We could package two majors of libsyncml at the
same time, you could even install them at the same time. Personally I'm
happy with this (just to remind anyone who's forgotten, I'm still not
the Fedora maintainer, that's still Andreas :> this is just my personal
opinion). I just don't see the point in taking the trouble unless
there's some way in which a libsyncml which doesn't work with opensync
will still be useful to anyone besides the libsyncml developers. If
there *is* some way - e.g. this syncml-ds-tool - then I'm personally
happy to think about that.
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org
http://www.happyassassin.net


------------------------------------------------------------------------------
_______________________________________________
Opensync-devel mailing list
Opensync-devel@...
https://lists.sourceforge.net/lists/listinfo/opensync-devel

[Juha Tuomala-2]

Some parts of this message have been removed. Learn more about Nabble's security policy.

On Friday 27 March 2009 20:07:52 Adam Williamson wrote:
> But what's the point? They don't *do* anything without opensync. What
> use is it having packages for current versions of these in a
> distribution if you can't do anything with them? Who does that help?

I've a feeling that wbxml is older project than opensync and like
mentioned, there are those userspace tools in libsyncml.

https://libwbxml.opensync.org/wiki/WBXMLLibraryUsers

There are lot of users for wbxml.

Having a plain lib in distro allows development, like any other tool does.

But I put a question mark to the subject, what we should do with that.
Having it will takes focus from testing, if you're fine with that, ok.

Just get that damn 0.40 out and we can all start skimming bugs out it
and move on.

Tuju

--
Varo hattupäisiä autoilijoita.

------------------------------------------------------------------------------

_______________________________________________
Opensync-devel mailing list
Opensync-devel@...
https://lists.sourceforge.net/lists/listinfo/opensync-devel

[Adam Williamson-4]

On Fri, 2009-03-27 at 21:06 +0200, Juha Tuomala wrote:

> On Friday 27 March 2009 20:07:52 Adam Williamson wrote:
> > But what's the point? They don't *do* anything without opensync.
> What
> > use is it having packages for current versions of these in a
> > distribution if you can't do anything with them? Who does that help?

> I've a feeling that wbxml is older project than opensync and like
> mentioned, there are those userspace tools in libsyncml.

> https://libwbxml.opensync.org/wiki/WBXMLLibraryUsers

> There are lot of users for wbxml.

> Having a plain lib in distro allows development, like any other tool
> does.

> But I put a question mark to the subject, what we should do with that.
> Having it will takes focus from testing, if you're fine with that, ok.

As we just discovered in IRC, you can actually build libsyncml 0.4.6
against wbxml2 0.10.4 and it seems perfectly happy, so that solves that
problem.

Fedora could, as I mentioned, theoretically ship libsyncml 0.4.6 and
0.5.3 in parallel. I'm fine with supporting that as long as it's useful
to someone. It's up to Andreas if he wants to do the extra work for it,
though.
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org
http://www.happyassassin.net


------------------------------------------------------------------------------
_______________________________________________
Opensync-devel mailing list
Opensync-devel@...
https://lists.sourceforge.net/lists/listinfo/opensync-devel

[Michael Bell]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Adam Williamson wrote:
> On Fri, 2009-03-27 at 19:31 +0100, Daniel Gollub wrote:
>
>> But please check back with Michael Bell if he wants to have big PR about this
>> tool.
>
> OK. Thanks for the info. Michael? Do you think it's a good idea for
> distros to ship a current libsyncml package specifically to allow people
> to use syncml-ds-tool?

No, please don't do this. syncml-ds-tool can be used for synchronization
but is was mainly designed as tool to verify synchronization problems of
OpenSync. libsyncml is a library. I do not want to start with massive
end user support. I want that end users focus on OpenSync.

BTW I have simply not the time to do real end user support. So I want to
limit myself to things which I can do. End user systems should have more
than one developer which can support the users ;)

Best regards

Michael
- --
___________________________________________________________________

Michael Bell                        Humboldt-Universitaet zu Berlin

Tel.: [phone]           ZE Computer- und Medienservice
Fax:  [phone]           Unter den Linden 6
michael.bell@...       D-10099 Berlin
___________________________________________________________________

PGP Fingerprint: 09E4 3D29 4156 2774 0F2C  C643 D8BD 1918 2030 5AAB
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFJ0Ipd2L0ZGCAwWqsRAq/AAKC60vvAGjDP2BI8t+UX8D3Tv1mX6wCgwWjh
1PScV8XErc02uecRZTP60vw=
=b48d
-----END PGP SIGNATURE-----

------------------------------------------------------------------------------
_______________________________________________
Opensync-devel mailing list
Opensync-devel@...
https://lists.sourceforge.net/lists/listinfo/opensync-devel

[Michael Bell]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Adam Williamson wrote:
>
> As we just discovered in IRC, you can actually build libsyncml 0.4.6
> against wbxml2 0.10.4 and it seems perfectly happy, so that solves that
> problem.

FYI libwbxml 0.10.x is fully API compliant to libwbxml 0.9.2. It is the
same API in fact. The cmake stuff generates libraries with the correct
SO names. Daniel invested a lot of time in it.

Best regards

Michael
- --
___________________________________________________________________

Michael Bell                        Humboldt-Universitaet zu Berlin

Tel.: [phone]           ZE Computer- und Medienservice
Fax:  [phone]           Unter den Linden 6
michael.bell@...       D-10099 Berlin
___________________________________________________________________

PGP Fingerprint: 09E4 3D29 4156 2774 0F2C  C643 D8BD 1918 2030 5AAB
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFJ0Ir72L0ZGCAwWqsRAmMPAKCK/TNP7kL8sFE2hz4Q6CV6+yIkkgCffWFb
OolJV3+e6jrKLM/rUMtYYKg=
=JwrF
-----END PGP SIGNATURE-----

------------------------------------------------------------------------------
_______________________________________________
Opensync-devel mailing list
Opensync-devel@...
https://lists.sourceforge.net/lists/listinfo/opensync-devel