Re: [Opensync-users] Fwd: Google plugin for opensync

[Quentin D. <que...@gm...>]

On Fri, Aug 13, 2010 at 11:09 PM, Chris Frey <cd...@fo...> wrote:
>
>
> I quite agree with the above, and I think the first step in fixing this
> situation is to bring all the engine and plugin sources together into
> one SVN or git repository, and get rid of the SVN externals stuff, which
> makes it harder to interface with other SCM software.
>
> If it is possible for a developer to make a change in the engine, and
> run 'make' and automatically compile all plugins and thereby test that
> the API has at least been updated for all plugins, I think development
> would be smoother.  Sort of like how the linux kernel has all the modules
> included, and if you change the kernel, the modules break automatically,
> and the compiler helps you update things.
>
>
> ATTENTION anyone reading this thread: please let me know if this will cause
> trouble that I don't foresee.  I plan to update at least the opensync SVN
> to get rid of its externals if possible, and put all plugins into it.
>
>
I have followed the discussion "SCM changes"; but I prefer to reply in this
thread since my contribution to the topic is not of a valuable experience.
All I notice is that you have a serious API and/vs Plugin problem, probably
also source of all wilting on contributor's side. In my opinion:
- engine and plugins should be maintained together, anyone who changes the
engine breaking the plugins should fix the latter
- plugins should be released with the engine; it makes to sense to have an
engine without plugins. If a user's favorite plugin is not shipped with the
release, the suite is useless for him. (imagine Linux kernel release with
missing modules...)
- you can put plugins and engine together in a tarball (and in the trunk)
because they belong together (see point above). It will also be easier to
see which ones are broken. Furthermore, it should not be a problem for
packagers, even if the transition would require to rewrite the spec file(s),
the result would be easier to maintain. I am a (former?) packager and know
how to deal with that, all this being my personal opinion.
- don't waste time on developer's environment changes or details, forget
about porting svn to git; don't waste time on CDash and automated testing
environments, hurry up to bring FINALLY the stable 0.4 version.
- give yourself and the users DEADLINES!!!, publish them on the roadmap.
Users want to know release dates, or they get discouraged!


>
> I see you've already updated the wiki... nice!  Thanks!
>

That's not even the beginning, I currently have no time and will start only
in one week to work on the wiki page, i.e. homepage. I will fresh it up, but
maybe I will require some admin rights (my username is "denisq"). For
example, the search function is broken, let me fix it, let me bring some
bigger changes to, give me access to the sources.



> You also mentioned "tasks" in your earlier email... I can see libgcal API
> for contacts and calendar, but not sure about tasks.
>

If you have a google account, you will see that gmail is now featuring
"Tasks". I don't know if Adenilson already implemented it, but it is not one
of the most important features right now. We'll come back to that one later,
Contact and Calendar is far more important.


> I'm close to committing some patches to the google-calendar plugin
> that gets calendar working nicely again.  Just have to hammer out some
> timestamp conversion issues.


Nice, it will make me and others happy. ...even if it is only a fraction of
happiness compared to the apparition of an Akonadi plugin! ;)

Please give us release dates for beta, RC and final stable 0.4!