Menu
▾
▴
opensync-devel
|
From: Daniel G. <go...@b1...> - 2009-10-19 16:29:43
|
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: +49-(0)-160 47 73 970 Handelsregister: HRB 3537
EMail: go...@b1... 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
|
|
From: Chris F. <cd...@fo...> - 2009-10-19 18:38:21
|
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. |
|
From: Daniel G. <go...@b1...> - 2009-10-19 19:14:43
|
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: +49-(0)-160 47 73 970 Handelsregister: HRB 3537 EMail: go...@b1... 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 |
|
From: Chris F. <cd...@fo...> - 2009-10-19 20:16:15
|
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. |
|
From: Paul E. <blu...@bl...> - 2009-10-19 22:31:22
|
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 |
|
From: Daniel G. <go...@b1...> - 2009-10-20 21:44:07
|
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: +49-(0)-160 47 73 970 Handelsregister: HRB 3537 EMail: go...@b1... 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 |
|
From: Michael B. <mb...@de...> - 2009-10-20 08:06:52
|
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 |
|
From: Juha T. <Juh...@ik...> - 2009-10-20 08:52:01
|
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. |
|
From: Henrik /K. <kaa...@us...> - 2009-10-20 16:36:08
|
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 |
|
From: Daniel G. <go...@b1...> - 2009-10-20 16:39:58
|
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: +49-(0)-160 47 73 970 Handelsregister: HRB 3537 EMail: go...@b1... 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 |
|
From: Henrik /K. <kaa...@us...> - 2009-10-20 20:00:56
|
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 |
|
From: Dirk W. <pr...@go...> - 2009-10-20 18:20:34
|
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 |
|
From: Daniel G. <go...@b1...> - 2009-10-24 13:17:20
|
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: +49-(0)-160 47 73 970 Handelsregister: HRB 3537 EMail: go...@b1... 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 |
|
From: Daniel G. <go...@b1...> - 2009-10-20 21:25:55
|
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: +49-(0)-160 47 73 970 Handelsregister: HRB 3537 EMail: go...@b1... 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 |
|
From: Chris F. <cd...@fo...> - 2009-10-20 23:02:30
|
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 |
|
From: Jakub M. <ja...@o2...> - 2009-10-25 20:25:24
|
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 ja...@o2... |
|
From: Graham C. <g+o...@co...> - 2009-10-26 09:47:17
|
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 |
|
From: Graham C. <g+o...@co...> - 2009-10-26 10:26:19
|
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 |
|
From: <he...@ka...> - 2009-10-26 12:01:00
|
> 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 |
|
From: Daniel G. <go...@b1...> - 2009-10-29 13:23:21
|
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: +49-(0)-160 47 73 970 Handelsregister: HRB 3537 EMail: go...@b1... 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 |
Thanks for helping keep SourceForge clean.
X