Re: [Evolution] MAPI exchange bits




On Thu, 2007-11-29 at 08:37 -0800, C.J. Adams-Collier wrote:
On Thu, 2007-11-29 at 15:22 +0530, Srinivasa Ragavan wrote:
Hey,

On Wed, 2007-11-28 at 12:29 -0800, C.J. Adams-Collier wrote:
Hey there Srini, list,

I spoke with you the other day on IRC about the upcoming MAPI release.
I'm jhbuild'ing evolution now and will check out and build from
EXCHANGE_MAPI_BRANCH after everything builds correctly from trunk.


What is the policy regarding committing patches to this branch?
We commit every few lines on our disk to the branch :)

Does "we" include me? :)

It is all open-sourced. You are free to help us with patches :)

My mail admins moved my mailbox from an exchange 2003 server to 2007
without telling me first.  This caused a few days of downtime and quite
a bit of frustration.  I'd like to start using the "official" interface
to the exchange server in order to minimize this type of problem in the
future.

How closely is the Evolution team working with the Exchange team? 
Part of the evolution team at Novell is doing this work. I don't
think/know of any agreement for MAPI/Evolution related in that. We are
using OpenChange based libmapi to connect to the Exchange Server and it
works pretty well.

I was looking for a pre-release this week but due to some issues and
holidays in India I think this might be pushed a week or two later. In
the whole I'm looking at a feature complete around GNOME 2.22 release.
Unfortunately I'm not sure, if I can commit to the GNOME release or not,
since this code has some licensing issues which I'm still working at
Novell to clear them off.

If I can help with that, let me know.  I'm biking distance from the
Exchange team.
Sure. 

Only after that I can commit the code to the
Evolution trunk.

Is this keeping you from committing to the EXCHANGE_MAPI_BRANCH branch?
It sounds like it's not.  How often are changes from trunk integrated
back to the MAPI branch?
I really don't want to push any code that has licensing issues into the
main tarball and developing in a branch and merging later would be fine,
since it helps to keep the stability of the trunk. Changes from the
trunk aren't integrated to the branch. Later some point, I would merge
the branch to trunk. It should be pretty simple IMO

Evolution/
        configure.in
        plugins/exchange-mapi

EDS/
        configure.in
        addressbook/backend/mapi
        calendar/backend/mapi
        camel/providers/mapi
        servers/mapi

These are the directories and just the configure.in and Makefile.am
would be the real merge work. I could have made this a conditional
compilation in trunk, but still I want to do the initial things in a
branch and merge.


Till then I'm hoping is to have weekly/biweekly
opensuse buildservice packages for SUSE/Fedora/Debian (What ever OBS
supports) for testing and help us back. If any one wants to help us in
getting the OBS ready, your help is welcome.

Hmmm... What's OBS, and does it build RHEL3 packages, perchance?
OBS - OpenSUSE Build Service. (RHEL3? I really donno. It sure builds for
fedora/OpenSUSE/debian). So it may...

-Srini.




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