Fixing the OpenSync core development BUS factor

[Daniel Gollub-3]

Hi,

we have a pretty low BUS factor [1] for OpenSync core development. Which is, i
guess, the primary reason why the OpenSync development is so slow ...

Everytime when Björn or I disappear for some weeks the development is kind of
frozen.

This is frustrating the OpenSync community ...

And for developers it's pretty hard to start with OpenSync core developer due
to missing documentation or comments completely. So in the past Björn and I
tried this:

We tried to fix all the tickets which are oustanding for the next development
milestone. If there where any question from other developers we tried to
answer them in time ... later thing didn't work as often as it should be.
Especially if there were certain questions only I was able to reply ... and
haven't, due to lack of time ... i'm sure i also missed some question to
answer the last month, because i was so busy with private things that i was
away from development for weeks.

So how should we solve the problem?
Should i declare OpenSync as dead? Or should i stop mainting the project and
hand it over to someone else? If anyone thinks this would help ... please let
me and the others know. Currently I'm certianly not the best choices as a
maintainer due to the lack of time i can spent on this project. But maybe i
still have some understanding how OpenSync in detail works, which could be
very valuable to finally complete this project ...

I want to suggest now that we _all_ should try something new:

We look for volunteers who are interested in becoming OpenSync core
contributors and assign special components of the core to them. There is no
deep knowledge in OpenSync core development required today ... just the
willing to help the OpenSync development and maybe some very basic C
programming is required (i leanred C also while programming on OpenSync ... so
don't hesistate to start here as well).

My role will be just kind of a mentor, and i just try to be available for
question as much as possible and will do only developing and debugging if
there is no pending questions from the other core developers.

Are there any volunteers for following components?

 - Application API
   * main objective: API review and keeping it stable
   * documentatoin
 - (Sync) Plugin API
   * main objective: API review and keeping it stable
    * documentation
 - Format Plugin API
   * main objective: API review and keeping it stable
   * documentation
 - Synchronization Engine (workflow of the Synchronization: connect,
   get_changes, ...)
   * documentation
   * cleanup
   * maintenance
   * bugfixing
   * profiling
 - Format Conversion (abstract logic to convert formats, e.g. conversion
   pathes, ...)
   * review of the conversion path building process
   * profiling
   * documentation
 - Mapping Logic (abstract logic to compare and map similar/same entries)
   * review of the logic
   * documentation
   * bugfixing
 - Capabilties, Merger and Demerger
   * completing capabilities merger/demerger implementation
   * documentation
 - IPC
   * maintenance
   * (porting work to different platforms)
   * documentation




The idea primary idea is not that you took the component you need to fix
anyway because your plugin xyz is currently not working because of xyz. The
primary idea is just to start to contribute to OpenSync core ... and since
we're primarily lacking on documentation we should start with reviewing the
code and document how things work .. to make it easier for other developers to
understand and contribute code.


[1] http://en.wikipedia.org/wiki/Bus_factor

Best Regards,
Daniel

--
Daniel Gollub                        Geschaeftsfuehrer: Ralph Dehner
FOSS Developer                       Unternehmenssitz:  Vohburg
B1 Systems GmbH                      Amtsgericht:       Ingolstadt
Mobil: [phone]         Handelsregister:   HRB 3537
EMail: gollub@...          http://www.b1-systems.de

Adresse: B1 Systems GmbH, Osterfeldstraße 7, 85088 Vohburg
http://pgpkeys.pca.dfn.de/pks/lookup?op=get&search=0xED14B95C2F8CA78D


------------------------------------------------------------------------------
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
_______________________________________________
Opensync-devel mailing list
Opensync-devel@...
https://lists.sourceforge.net/lists/listinfo/opensync-devel

[Chris Frey-2]

On Mon, Oct 19, 2009 at 06:29:24PM +0200, Daniel Gollub wrote:
> I want to suggest now that we _all_ should try something new:
>
> We look for volunteers who are interested in becoming OpenSync core
> contributors and assign special components of the core to them. There is no
> deep knowledge in OpenSync core development required today ... just the
> willing to help the OpenSync development and maybe some very basic C
> programming is required (i leanred C also while programming on OpenSync ... so
> don't hesistate to start here as well).

Continuing from my previous email in the other thread....

There are two pools of developers:

        A) developers who have lots of free time and are looking for
                a project to significantly contribute to

        B) developers who are solving their own problems and willing to
                help another project only so far as it helps them

Pool B is a whole lot bigger than pool A.

The above strategy only targets pool A.  We're publishing a list of bugs,
and asking who wants to step up and fix them.

Going with my suggestion (see other email on losing API stability)
targets both pools, since:

        - everybody is using the latest code

        - any bug that needs to be fixed, or feature that needs to be
                implemented, will be felt immediately

        - anyone who feels that need, will have the ability to scratch
                that itch immediately, and see their work released
                within a month, thereby solving both OpenSync's problem
                and their own in real time

One of those needs is documentation.  I think releasing 0.5x and dropping
API stability will help fix that too.

People need to be invested in the current code, not 0.22.  Right now,
0.22 doesn't solve their needs, and 0.4x is held up by artificial constraints,
so people are developing their own non-API-stable platforms.

- Chris


--
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.


------------------------------------------------------------------------------
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
_______________________________________________
Opensync-devel mailing list
Opensync-devel@...
https://lists.sourceforge.net/lists/listinfo/opensync-devel

[Daniel Gollub-3]

On Monday 19 October 2009 08:37:13 pm Chris Frey wrote:

> On Mon, Oct 19, 2009 at 06:29:24PM +0200, Daniel Gollub wrote:
> > I want to suggest now that we _all_ should try something new:
> >
> > We look for volunteers who are interested in becoming OpenSync core
> > contributors and assign special components of the core to them. There is
> > no deep knowledge in OpenSync core development required today ... just
> > the willing to help the OpenSync development and maybe some very basic C
> > programming is required (i leanred C also while programming on OpenSync
> > ... so don't hesistate to start here as well).
>
> Continuing from my previous email in the other thread....
>
> There are two pools of developers:
>
> A) developers who have lots of free time and are looking for
> a project to significantly contribute to
>
> B) developers who are solving their own problems and willing to
> help another project only so far as it helps them
>
> Pool B is a whole lot bigger than pool A.
>
> The above strategy only targets pool A.  We're publishing a list of bugs,
> and asking who wants to step up and fix them.

Actually i planned to target also pool B - at least some of them.
Do you see any chance that i get any of those?

[...]

Best Regards,
Daniel

--
Daniel Gollub                        Geschaeftsfuehrer: Ralph Dehner
FOSS Developer                       Unternehmenssitz:  Vohburg
B1 Systems GmbH                      Amtsgericht:       Ingolstadt
Mobil: [phone]         Handelsregister:   HRB 3537
EMail: gollub@...          http://www.b1-systems.de

Adresse: B1 Systems GmbH, Osterfeldstraße 7, 85088 Vohburg
http://pgpkeys.pca.dfn.de/pks/lookup?op=get&search=0xED14B95C2F8CA78D


------------------------------------------------------------------------------
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
_______________________________________________
Opensync-devel mailing list
Opensync-devel@...
https://lists.sourceforge.net/lists/listinfo/opensync-devel

[Chris Frey-2]

On Mon, Oct 19, 2009 at 09:14:27PM +0200, Daniel Gollub wrote:
> Actually i planned to target also pool B - at least some of them.
> Do you see any chance that i get any of those?

I liked your topical list.  That kind of project breakdown is good for
anyone to get a mental handle on things.

But I can only talk from my own experience here, which is as part of
the team for the barry-sync plugin.

I don't really have time to read all the code in opensync, so I end up
focusing on the parts that pertain to me.  This ends up being the plugin
API, learning as I go, and the opensync_time.c functions, which I
started looking at back when I was trying to do timezone stuff correctly.
(Still haven't finished that in the barry-sync plugin.)

Also, I've been working a bit on the application side of the opensync API,
and I find little things there too.  If I can read the code and submit
a fix, I just go ahead and commit it.

So that's 3 areas that I'm interested in: plugin API, time functions, and
application side API.  But I don't have the time to volunteer to take
charge of any of them, only to contribute where I bump into issues.

So, while I consider myself in pool B, unfortunately I'm passing by
your list completely, since I'm not in pool A, and don't have the time
to take on any more responsibility.

Not sure if that answers your question...

- Chris


--
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.


------------------------------------------------------------------------------
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
_______________________________________________
Opensync-devel mailing list
Opensync-devel@...
https://lists.sourceforge.net/lists/listinfo/opensync-devel

On Mon, 19 Oct 2009, Daniel Gollub wrote:
> So how should we solve the problem?
> Should i declare OpenSync as dead?

If you ask me I don't think so. OpenSync still has too much promise and there
has been too much work put into it already to just let it go. (Then again I am
the one keeping a handheld environment alive that is still using Qt2 and is
now over 7 years old (!) - so perhaps I am not the best person to ask :)
Still, my statement stands.

> Or should i stop mainting the project and hand it over to someone else?

Well that depends on someone being willing and able to step forward and do it.
Myself, I'm not unwilling per se, but I don't feel sufficiently armed with the
knowledge yet to fix many of the bugs that are open, and without that I
wouldn't feel confident in being the maintainer. In any case I think the title
is less important than people actually doing the work that needs to be done,
whoever those people might be :)

> I want to suggest now that we _all_ should try something new:
>
> We look for volunteers who are interested in becoming OpenSync core
> contributors and assign special components of the core to them.

The trend I have observed in open source projects is that most contributors
are either driven by commercial needs (rare) or they are students with lots of
spare time and enthusiasm. Actually I don't fall into either of these
categories; I seem to have been able to preserve a lot of my spare time and
enthusiasm even though I am out at work (perhaps because my daily work is not
as stimulating as some of the open source projects that I get to work on);
however I still think the latter group (students) is where we will find new
recruits.

I think broadly though (and this is just restating what we have already been
discussing) we just need to lower the barrier to entry for new people to get
involved. Also I think that any project also has to work reasonably well (at
least some part of it) for people to be enthusiastic about working on it - if
it just seems like a bucket of bolts they may decide it's not worth their time
or feel that they're not confident enough in their abilities to take it on.

> My role will be just kind of a mentor, and i just try to be available for
> question as much as possible and will do only developing and debugging if
> there is no pending questions from the other core developers.

That sounds great. If you can try to pass on some of your knowledge then
hopefully the rest of us will be able to take some of the burden of assisting
users and other developers. I guess if you will be in a position to answer
people's questions as much as possible then you may need to consider how you
can set a balance between this and your personal commitments. But that is a
question for you of course :)

I'm not quite sure how to decide which areas I would work on in the core; as
you say there is great temptation to take on the areas that are most important
to me as a plugin developer. I agree though that that will ultimately not
solve anything.

I have some hesitation in doing this, but perhaps if I can take these two
items for now:

>  - Synchronization Engine (workflow of the Synchronization: connect,
>    get_changes, ...)
>    * documentation
>    * cleanup
>    * maintenance
>    * bugfixing
>    * profiling
>  - Format Conversion (abstract logic to convert formats, e.g. conversion
>    pathes, ...)
>    * review of the conversion path building process
>    * profiling
>    * documentation

I don't know if we have much time for profiling at the moment :) Bugfixes and
understanding & documenting the process are a lot more important right now. I
am still also ready to do fixes and completion of the API documentation in any
of the areas required, but what I am usually lacking there is understanding
about how some of the functions should work.

Cheers,
Paul

------------------------------------------------------------------------------
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
_______________________________________________
Opensync-devel mailing list
Opensync-devel@...
https://lists.sourceforge.net/lists/listinfo/opensync-devel

[Michael Banck]

On Mon, Oct 19, 2009 at 06:29:24PM +0200, Daniel Gollub wrote:
> Everytime when Björn or I disappear for some weeks the development is kind of
> frozen.

Maybe it would help to go into more detail in what kind of development
exactly is still needed for 0.40.  Is there still a lot to do?  Or
rather just responding to bugs?

Once 0.40 is out, presumably the ball is in the hands of the plugin
writers and the core is in maintenance mode, until somebody steps up and
starts to do major changes (probably not you).


Michael

------------------------------------------------------------------------------
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
_______________________________________________
Opensync-devel mailing list
Opensync-devel@...
https://lists.sourceforge.net/lists/listinfo/opensync-devel

[Juha Tuomala-2]

On Monday 19 October 2009 21:37:13 Chris Frey wrote:
> - everybody is using the latest code
> - any bug that needs to be fixed, or feature that needs to be
> implemented, will be felt immediately
> - anyone who feels that need, will have the ability to scratch
> that itch immediately, and see their work released
> within a month, thereby solving both OpenSync's problem
> and their own in real time

> People need to be invested in the current code, not 0.22.  Right now,
> 0.22 doesn't solve their needs,

That's what i suggested a long time ago. We need to officially
announce 0.22 dead, kill it. Fedora upgraded their versions to 0.3x and
then reverted back to 0.22 even i tried to stop that idea there too. :)

If you want to keep everyones eyeballs out of focus (current code), best
way to do is to distract them to look something else. _Opensync is a name
that stands for the concept of pda syncing_. Everyone knows it already.

People stare at the 0.22 and see that's it is not good for anything else
than filling a package in distro.

That damages both our needs (more eyeballs) and the name. There is no need
to keep an active placeholder in distros, since everyone knows the name already.

So, i suggest (with quite minimal effort):

- drop 0.22
- leave space empty or...

  Perhaps we should just lift the ban to upgrade distro releases for 0.39?
  That is - announce that it's very close to finished API and everyone should
  package it now, since once the possible fixes to API happen in next releases,
  those will not be big changes in apps and wont cause lot to work to update.
  Then it would not break the promise of 0.40 with stable api and make people
  stare the current code.

There are not many (or none) using the 0.3x api except our own tools, so people
using those would be able to easily test it via distro packages and we would
be able to do the remaining work until anyone really puts lot of effort to 0.39
api in app - which anyway wont be that much different from 0.40 proper.

btw, Chris you've very valid points in your comments, keep them coming.


Tuju

--
Better to have one, and not need it, than to need one and not have it.

------------------------------------------------------------------------------
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
_______________________________________________
Opensync-devel mailing list
Opensync-devel@...
https://lists.sourceforge.net/lists/listinfo/opensync-devel

[Henrik /KaarPoSoft]

Daniel Gollub wrote:

> Hi,
>
> we have a pretty low BUS factor [1] for OpenSync core development. Which is, i
> guess, the primary reason why the OpenSync development is so slow ...
>
> Everytime when Björn or I disappear for some weeks the development is kind of
> frozen.
>
> We look for volunteers who are interested in becoming OpenSync core
> contributors and assign special components of the core to them. There is no
> deep knowledge in OpenSync core development required today ... just the
> willing to help the OpenSync development and maybe some very basic C
> programming is required (i leanred C also while programming on OpenSync ... so
> don't hesistate to start here as well).
>  

The mozilla-sync plugin is more than enough for me already, so I cannot
volunteer for maintanership of any parts of the OpenSync core.

However, I do have a question:

Until now, when I have found bugs, I have filed tickets - sometimes with
patches.
As a result, others have either rejected the patches, committed them, or
committed them in a modified form.
Would it be beneficial if I just check in my patches directly?

(Bear in mind, that I still understand so little of OpenSync, that in
something like one in three I am wrong and break things.
So it would be a two steps forward but one step back approach)

/Henrik


------------------------------------------------------------------------------
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
_______________________________________________
Opensync-devel mailing list
Opensync-devel@...
https://lists.sourceforge.net/lists/listinfo/opensync-devel

[Daniel Gollub-3]

On Tuesday 20 October 2009 06:35:51 pm Henrik /KaarPoSoft wrote:
> Until now, when I have found bugs, I have filed tickets - sometimes with
> patches.
> As a result, others have either rejected the patches, committed them, or
> committed them in a modified form.
> Would it be beneficial if I just check in my patches directly?
[...]

I would say this depends how complex your modification is. If your sure this
is a trivial modification go ahead and commit it (and make sure it passes the
entire testsuite and doesn't cause any regression).

If it's a more complex chance please always send the patch to opensync-devel
and ask for review. If there is no response within 2 days, feel free to commit
it directly ...


Does this sounds sane to you?

Best Regards,
Daniel


--
Daniel Gollub                        Geschaeftsfuehrer: Ralph Dehner
FOSS Developer                       Unternehmenssitz:  Vohburg
B1 Systems GmbH                      Amtsgericht:       Ingolstadt
Mobil: [phone]         Handelsregister:   HRB 3537
EMail: gollub@...          http://www.b1-systems.de

Adresse: B1 Systems GmbH, Osterfeldstraße 7, 85088 Vohburg
http://pgpkeys.pca.dfn.de/pks/lookup?op=get&search=0xED14B95C2F8CA78D

------------------------------------------------------------------------------
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
_______________________________________________
Opensync-devel mailing list
Opensync-devel@...
https://lists.sourceforge.net/lists/listinfo/opensync-devel

[Dirk Wischeropp]

Am Montag, den 19.10.2009, 18:29 +0200 schrieb Daniel Gollub:

> [...]
> I want to suggest now that we _all_ should try something new:
>
> We look for volunteers who are interested in becoming OpenSync core
> contributors and assign special components of the core to them. There is no
> deep knowledge in OpenSync core development required today ... just the
> willing to help the OpenSync development and maybe some very basic C
> programming is required (i leanred C also while programming on OpenSync ... so
> don't hesistate to start here as well).
>
> My role will be just kind of a mentor, and i just try to be available for
> question as much as possible and will do only developing and debugging if
> there is no pending questions from the other core developers.
>
> Are there any volunteers for following components?
> [...]

Yes there are. My name is Dirk and i am new to opensync. I am reading
this mailing list in a while and I am interested for this project.
I am studing computer science. I had considered some time ago to expand
my programming skills to participate in an open source project times.
Unfortunately I have only basic skills at this time.

But I hope I can help you?


Best regards

Dirk



------------------------------------------------------------------------------
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
_______________________________________________
Opensync-devel mailing list
Opensync-devel@...
https://lists.sourceforge.net/lists/listinfo/opensync-devel

[Henrik /KaarPoSoft]

Daniel Gollub wrote:

> On Tuesday 20 October 2009 06:35:51 pm Henrik /KaarPoSoft wrote:
>  
>> Until now, when I have found bugs, I have filed tickets - sometimes with
>> patches.
>> As a result, others have either rejected the patches, committed them, or
>> committed them in a modified form.
>> Would it be beneficial if I just check in my patches directly?
>>    
> [...]
>
> I would say this depends how complex your modification is. If your sure this
> is a trivial modification go ahead and commit it (and make sure it passes the
> entire testsuite and doesn't cause any regression).
>
> If it's a more complex chance please always send the patch to opensync-devel
> and ask for review. If there is no response within 2 days, feel free to commit
> it directly ...
>
>
> Does this sounds sane to you?
>
> Best Regards,
> Daniel
>
>  

Let's try it out !

/Henrik

------------------------------------------------------------------------------
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
_______________________________________________
Opensync-devel mailing list
Opensync-devel@...
https://lists.sourceforge.net/lists/listinfo/opensync-devel

[Daniel Gollub-3]

On Tuesday 20 October 2009 10:51:43 am Juha Tuomala wrote:
[...]

> That's what i suggested a long time ago. We need to officially
> announce 0.22 dead, kill it. Fedora upgraded their versions to 0.3x and
> then reverted back to 0.22 even i tried to stop that idea there too. :)
>
> If you want to keep everyones eyeballs out of focus (current code), best
> way to do is to distract them to look something else. _Opensync is a name
> that stands for the concept of pda syncing_. Everyone knows it already.
>
> People stare at the 0.22 and see that's it is not good for anything else
> than filling a package in distro.
>
> That damages both our needs (more eyeballs) and the name. There is no need
> to keep an active placeholder in distros, since everyone knows the name
>  already.
>
> So, i suggest (with quite minimal effort):
>
> - drop 0.22

No - otherwise people start packaging 0.39 and put it in a distro ...

> - leave space empty or...
>
>   Perhaps we should just lift the ban to upgrade distro releases for 0.39?

No - 0.39 is not working smooth enough ... there is this IPC issue we hit with
plugins like SyncML and others - which needs to be fixed.

The capsformat changes are not compleltey incoperatd.
Currently you only really can sync "contact" ... not any other PIM format ...

Currently only the demerger is active, but not the merger!


I don't want to debug 0.39 from regular users, which using 0.39 because it got
shipped by their distro. I only want to debug 0.39 from a small amount of
people which are acting as tester and are not get angry if things doesn't work
as expected and are more willing to help and response in time ... ;)


Best Regards,
Daniel


--
Daniel Gollub                        Geschaeftsfuehrer: Ralph Dehner
FOSS Developer                       Unternehmenssitz:  Vohburg
B1 Systems GmbH                      Amtsgericht:       Ingolstadt
Mobil: [phone]         Handelsregister:   HRB 3537
EMail: gollub@...          http://www.b1-systems.de

Adresse: B1 Systems GmbH, Osterfeldstraße 7, 85088 Vohburg
http://pgpkeys.pca.dfn.de/pks/lookup?op=get&search=0xED14B95C2F8CA78D

------------------------------------------------------------------------------
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
_______________________________________________
Opensync-devel mailing list
Opensync-devel@...
https://lists.sourceforge.net/lists/listinfo/opensync-devel

[Daniel Gollub-3]

On Tuesday 20 October 2009 12:31:06 am Paul Eggleton wrote:
[...]

> I'm not quite sure how to decide which areas I would work on in the core;
>  as you say there is great temptation to take on the areas that are most
>  important to me as a plugin developer. I agree though that that will
>  ultimately not solve anything.
>
> I have some hesitation in doing this, but perhaps if I can take these two
>
> items for now:
> >  - Synchronization Engine (workflow of the Synchronization: connect,
> >    get_changes, ...)
> >    * documentation
> >    * cleanup
> >    * maintenance
> >    * bugfixing
> >    * profiling
> >  - Format Conversion (abstract logic to convert formats, e.g. conversion
> >    pathes, ...)
> >    * review of the conversion path building process
> >    * profiling
> >    * documentation
>
> I don't know if we have much time for profiling at the moment :)

Yeah profiling is not so critical today ... we might do this with version 0.99
or so ;)

> Bugfixes
>  and understanding & documenting the process are a lot more important right
>  now.

ACK

>  I am still also ready to do fixes and completion of the API
>  documentation in any of the areas required, but what I am usually lacking
>  there is understanding about how some of the functions should work.
[...]

The easiest thing for me would be that you start with how the application API
get used - e.g. osynctool - or convtool (from vformat plugin - for format
conversion).


For Engine the public API function are acutally just those:

osync_engine_new()
osync_engine_initiazile()
osync_engine_synchronize_and_block() <- this is doin' the entire sync
osync_engine_finalize()
osync_engine_unref()

So i would suggest you start looking into osync_engine_initiazile() and
osync_engine_synchronize_and_block() ... there are also some junks in the
OpenSync how the inner engine works.

As soon you have question drop a mail on opensync-devel@

Maybe for the beginning you could try to find out the order of the plugin
calls in the engine - e.g. connect(), disconnect(), get_changes() ... and so
on ... once you find your way through that it's quite easy to find throught
the stack from engine call to the plugin call...

Best Regards,
Daniel


--
Daniel Gollub                        Geschaeftsfuehrer: Ralph Dehner
FOSS Developer                       Unternehmenssitz:  Vohburg
B1 Systems GmbH                      Amtsgericht:       Ingolstadt
Mobil: [phone]         Handelsregister:   HRB 3537
EMail: gollub@...          http://www.b1-systems.de

Adresse: B1 Systems GmbH, Osterfeldstraße 7, 85088 Vohburg
http://pgpkeys.pca.dfn.de/pks/lookup?op=get&search=0xED14B95C2F8CA78D

------------------------------------------------------------------------------
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
_______________________________________________
Opensync-devel mailing list
Opensync-devel@...
https://lists.sourceforge.net/lists/listinfo/opensync-devel

[Chris Frey-2]

On Tue, Oct 20, 2009 at 11:25:33PM +0200, Daniel Gollub wrote:
> I don't want to debug 0.39 from regular users, which using 0.39 because it got
> shipped by their distro. I only want to debug 0.39 from a small amount of
> people which are acting as tester and are not get angry if things doesn't work
> as expected and are more willing to help and response in time ... ;)

This is a good point. :-)


> On Tuesday 20 October 2009 10:51:43 am Juha Tuomala wrote:
> > - drop 0.22
>
> No - otherwise people start packaging 0.39 and put it in a distro ...

I think we should be encouraging distros to package both 0.22 and 0.4x.
The reason that Fedora got such flack for packaging 0.3x, in my opinion,
was because 0.22 disappeared.  The user needs to have a choice.

While 0.39 is not ready for production, there's no harm in packaging it
as long as it doesn't interfere with 0.22.

And fortunately, 0.39 won't interfere with 0.22 now.



> No - 0.39 is not working smooth enough ... there is this IPC issue we hit with
> plugins like SyncML and others - which needs to be fixed.
>
> The capsformat changes are not compleltey incoperatd.
> Currently you only really can sync "contact" ... not any other PIM format ...
>
> Currently only the demerger is active, but not the merger!

More good points. :-)

- Chris




------------------------------------------------------------------------------
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
_______________________________________________
Opensync-devel mailing list
Opensync-devel@...
https://lists.sourceforge.net/lists/listinfo/opensync-devel

[Daniel Gollub-3]

On Tuesday 20 October 2009 08:02:10 pm Dirk Wischeropp wrote:
> Yes there are. My name is Dirk and i am new to opensync. I am reading
> this mailing list in a while and I am interested for this project.
> I am studing computer science. I had considered some time ago to expand
> my programming skills to participate in an open source project times.
> Unfortunately I have only basic skills at this time.
>
> But I hope I can help you?

Sure you can.

First i would suggest that you get in touch with the build enviroment and
trunk/

Checkout latest trunk and build it and try to setup a group with two file-sync
plugins. For beginning core development this is bascially enough.

Try to do some syncing first - if you hit any problem - create a ticket and
try on your own to fix it. If you have trouble understanding the code - ask
here on the mailinglist. start a new thread for that ;)


If you like I can look for a trivial ticket to solve you can start with ... so
you have kind of a task to work on.


Thanks for your help!

Best Regards,
Daniel

--
Daniel Gollub                        Geschaeftsfuehrer: Ralph Dehner
FOSS Developer                       Unternehmenssitz:  Vohburg
B1 Systems GmbH                      Amtsgericht:       Ingolstadt
Mobil: [phone]         Handelsregister:   HRB 3537
EMail: gollub@...          http://www.b1-systems.de

Adresse: B1 Systems GmbH, Osterfeldstraße 7, 85088 Vohburg
http://pgpkeys.pca.dfn.de/pks/lookup?op=get&search=0xED14B95C2F8CA78D


------------------------------------------------------------------------------
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
_______________________________________________
Opensync-devel mailing list
Opensync-devel@...
https://lists.sourceforge.net/lists/listinfo/opensync-devel

[Jakub Marczynski]

Daniel Gollub mentioned several component to be taken care of:
 - Application API
 - (Sync) Plugin API
 - Format Plugin API
 - Synchronization Engine (workflow of the Synchronization: connect,
 - Format Conversion (abstract logic to convert formats, e.g. conversion
 - Mapping Logic (abstract logic to compare and map similar/same entries)
 - Capabilties, Merger and Demerger
 - IPC

I think I will be able to do some work on the project in the following
months, but:
- Due to very limited time (as most of us have) I would prefer to have
another person doing the same component with me. This way we increase the
BUS Factor even more.
- I'm afraid I'll need another 2-3 weeks to look through the opensync.org
website, the existing documentation, the code itself, to get some generall
idea how stuff work
- How can You (existing core developers) pass some knowledge to Us (new
developers) so that we know where to start and what to do? Did you think of
another IRC meetings? Or maybe some private Skype sessions ( 1 to 1) would
be more efficient?

---
Bloosky
jaquba@...


------------------------------------------------------------------------------
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
_______________________________________________
Opensync-devel mailing list
Opensync-devel@...
https://lists.sourceforge.net/lists/listinfo/opensync-devel

[Graham Cobb-4]

On Sunday 25 October 2009 20:25:15 Jakub Marczynski wrote:
> - Due to very limited time (as most of us have) I would prefer to have
> another person doing the same component with me. This way we increase the
> BUS Factor even more.

That sounds like a good idea.  We all have limited time and if there were a
couple of people working together in one area we could use it to discuss
ideas but also, hopefully, keep some more momentum going.  Of course, there
are also the problems of treading on each others toes which we would have to
manage.  One of the things that has frustrated me in the past is that I have
a suggestion or thought about an issue or a solution and no one seems to be
interested in discussing it with me!  Of course, I am guilty of exactly the
same thing in other areas.

> - I'm afraid I'll need another 2-3 weeks to look through the opensync.org
> website, the existing documentation, the code itself, to get some generall
> idea how stuff work

Do post questions here.  Although Daniel and Bjorn are the main experts I am
happy to commit to reading and answering when I can.

> - How can You (existing core developers) pass some knowledge to Us (new
> developers) so that we know where to start and what to do? Did you think of
> another IRC meetings? Or maybe some private Skype sessions ( 1 to 1) would
> be more efficient?

Scheduling IRC meetings can be difficult, although I think many of the
developers are in Europe.  For me personally it is a problem because my job
requires a lot of travel (both East and West) so I can't commit to any
regular meetings.  

Where possible it would be great to keep discussions in the open, and in an
archive, to help others.  Is the IRC channel archived?  However, if there are
a couple of people working in one area then voice discussions can also work
(although I would still encourage email dicussions to happen on the list so
others can learn and can contribute).

Graham

------------------------------------------------------------------------------
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
_______________________________________________
Opensync-devel mailing list
Opensync-devel@...
https://lists.sourceforge.net/lists/listinfo/opensync-devel

[Graham Cobb-4]

On Monday 19 October 2009 17:29:24 Daniel Gollub wrote:
> So how should we solve the problem?
> Should i declare OpenSync as dead? Or should i stop mainting the project
> and hand it over to someone else? If anyone thinks this would help ...
> please let me and the others know. Currently I'm certianly not the best
> choices as a maintainer due to the lack of time i can spent on this
> project. But maybe i still have some understanding how OpenSync in detail
> works, which could be very valuable to finally complete this project ...

If someone with more time wants to aim to take over that might (or might not)
be a good idea.  But not until they have gathered experience and support by
making major contributions.  So I don't see any challengers for your position
for quite a while :-)

> Are there any volunteers for following components?

I wonder if we are going about this the wrong way?  It is extremely logical to
get the core working properly before worrying about the plugins.  But it
doesn't seem to be working in motivating developers.  

I think part of the problem is that while the format plugins (in particular)
are broken, no one can use the code they are working on.  I find I am more
motivated to work on the engine if I am solving problems which allow me to
make progress with my personal goals, and my personal usage.

How about, now that the engine API is **reasonably** stable, we concentrate on
getting the plugins to work.  Solve some problems like timezones,
recurrences, conversions, etc. and get basic sync working for both contacts
and events (at least).  Don't even worry about merge/demerge for the moment.  
That would give us something which, while not releasable to end users, would
at least allow the developers to start using it in their daily lives.  The
developers would then start to hit the remaining engine problems
(capabilities, timeouts, IPC deadlocks, conversion paths, mapping, etc.) and
would be more motivated to work on them.

Of course, the danger is that developers do not try to fix the engine problems
if things are working "well enough" for them.  But that can't be worse than
the current situation where no progress is happening at all.  And it would
encourage new developers -- I don't see how we are going to get new people to
join when things are as theoretical as they are now: people want to be able
to try things.

Just an idea -- what do others think?

Graham

------------------------------------------------------------------------------
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
_______________________________________________
Opensync-devel mailing list
Opensync-devel@...
https://lists.sourceforge.net/lists/listinfo/opensync-devel

[Henrik /KaarPoSoft-2]

> I wonder if we are going about this the wrong way?  It is extremely
> logical to
> get the core working properly before worrying about the plugins.  But it
> doesn't seem to be working in motivating developers.
>
> I think part of the problem is that while the format plugins (in
> particular)
> are broken, no one can use the code they are working on.  I find I am more
> motivated to work on the engine if I am solving problems which allow me to
> make progress with my personal goals, and my personal usage.
>
> How about, now that the engine API is **reasonably** stable, we
> concentrate on
> getting the plugins to work.  Solve some problems like timezones,
> recurrences, conversions, etc. and get basic sync working for both
> contacts
> and events (at least).  Don't even worry about merge/demerge for the
> moment.
> That would give us something which, while not releasable to end users,
> would
> at least allow the developers to start using it in their daily lives.  The
> developers would then start to hit the remaining engine problems
> (capabilities, timeouts, IPC deadlocks, conversion paths, mapping, etc.)
> and
> would be more motivated to work on them.

I think we need to work in all areas at the same time (engine,
format-plugins, sync-plugins).
If we do not develop engine and format-plugins, the sync-plugins will not
work.
If we do not develop sync-plugins, we will not find and fix the problems
in the engine.

For one particular plugin (mozilla-sync) I can say that without
capabilities, demerger and IPC it simply does not work.

Do not forget that many of the bug reports for the engine comes from
testers and plugin developers hitting a wall, not from a general wish to
finish the loose ends in the engine in itself.

/Henrik


------------------------------------------------------------------------------
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
_______________________________________________
Opensync-devel mailing list
Opensync-devel@...
https://lists.sourceforge.net/lists/listinfo/opensync-devel

[Daniel Gollub-3]

On Monday 26 October 2009 11:26:03 am Graham Cobb wrote:
> > Are there any volunteers for following components?
>
> I wonder if we are going about this the wrong way?  It is extremely logical
>  to  get the core working properly before worrying about the plugins.  But
>  it doesn't seem to be working in motivating developers.

Good point ...

>
> I think part of the problem is that while the format plugins (in
>  particular)  are broken, no one can use the code they are working on.  I
>  find I am more motivated to work on the engine if I am solving problems
>  which allow me to make progress with my personal goals, and my personal
>  usage.
>
> How about, now that the engine API is **reasonably** stable, we concentrate
>  on  getting the plugins to work.  Solve some problems like timezones,
>  recurrences, conversions, etc. and get basic sync working for both
>  contacts and events (at least).  Don't even worry about merge/demerge for
>  the moment. That would give us something which, while not releasable to
>  end users, would at least allow the developers to start using it in their
>  daily lives.  The developers would then start to hit the remaining engine
>  problems
> (capabilities, timeouts, IPC deadlocks, conversion paths, mapping, etc.)
>  and  would be more motivated to work on them.

Currently i do only basic testing with contact syncing. No event/todo calendar
syncing or so ... since event/todo format handling is more complex and has
still lots of FIXMEs in place ...

But i guess it doesn't change anyhting if i just recommend that concentrate on
contact syncing -not on calendar syncing for timing being.

I hesistate a bit working on calendar syncing since this is extremly time
consuming, and also could done by other/new developers which are not so much
in the core of OpenSync.

Another reason why i'm not concentrating on calendar-syncing is that i still
think of replacing XMLFormat-plugin with another common-format plugin which is  
based on some PIM-Format-handler library ... something which came up when we
talked how Synthesis and OpenSync could benefit from each other .. there the
idea of a libvxx  came up ... maybe something we should look into before we
start fixing the calendar-format plugins?


>
> Of course, the danger is that developers do not try to fix the engine
>  problems  if things are working "well enough" for them.  But that can't be
>  worse than the current situation where no progress is happening at
>  all.  And it would encourage new developers -- I don't see how we are
>  going to get new people to join when things are as theoretical as they are
>  now: people want to be able to try things.

Fully agree!

So the bottom-line is that we need to get something working ... so developers
can play with it and start fixing other stuff. For me this means i need to do
another bug-screening round and check for bugs which block people for basic
use ... or could someone else screen the open tickets for such issues, so we
get re-priorties tickets to work on?

In meanwhile i try to reply to all the techincal question mails ...

--
Daniel Gollub                        Geschaeftsfuehrer: Ralph Dehner
FOSS Developer                       Unternehmenssitz:  Vohburg
B1 Systems GmbH                      Amtsgericht:       Ingolstadt
Mobil: [phone]         Handelsregister:   HRB 3537
EMail: gollub@...          http://www.b1-systems.de

Adresse: B1 Systems GmbH, Osterfeldstraße 7, 85088 Vohburg
http://pgpkeys.pca.dfn.de/pks/lookup?op=get&search=0xED14B95C2F8CA78D

------------------------------------------------------------------------------
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
_______________________________________________
Opensync-devel mailing list
Opensync-devel@...
https://lists.sourceforge.net/lists/listinfo/opensync-devel