On Nov 29, 2007 8:07 PM, Srinivasa Ragavan <[EMAIL PROTECTED]> wrote:
> > 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: > > > > 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 :) > Alrighty, but the real question is: would you prefer to review the patches first, or would you mind me committing sans review, since this is a branch and not the trunk? > > 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 > Okay, so long as the GNOME Foundation doesn't mind having code with "licensing issues" in their repository (be it in a branch or the trunk). I'll look into integrating changes from the trunk back into EXCHANGE_MAPI_BRANCH as a first project. jhbuild completed the build of evolution (and dependencies) from trunk yesterday, and I began the process of gathering dependencies for the MAPI branch. I don't think I have the ./configure args set up the way I want just yet, but I'm getting close... Debian's libcupsys2-dev provides headers and libs on which evolution-data-servers depends. However, libcupsys2-dev claims dependence on libkrb5-dev where I've been using heimdal-dev. I sent a patch to them to change from libkrb5-dev to libkrb5-dev | heimdal-dev and built the patched .deb myself. This allows me to use mostly stock .deb packages to meet build requirements and still provide kerberos5 libs & headers for my preferred implementation. > > 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. Okay. I'll keep this in mind. > I could have made this a conditional > compilation in trunk, but still I want to do the initial things in a > branch and merge. > This is a wise policy :) Conditionals should be avoided. They cause "edge cases" which are difficult to exercise thoroughly. Speaking of testing, how do I run the regression suite? make check? > > 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... > Alrighty. The supported corporate dev desktops are all RHEL3, so I'm sure the devs here would appreciate an .rpm they can install with minimal effort. > -Srini. > Cheers, C.J. -- moo.
_______________________________________________ Evolution-list mailing list Evolution-list@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-list
