On Fri, 2007-11-30 at 11:41 -0800, C.J. Adams-Collier wrote: > 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?
You need to gain the maintainers confidence to commit with out review ;-) Even for most of our patches, we do internal review. Lot of time, even my patches I get them reviewed by someone to be more confident. The review process shouldn't stop you really :) > > > > > 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 now nothing automated AFAIK. We have our test team who do their part. > > > > > 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. Im just not sure of the OBS support for RHEL3. -Srini. > > -Srini. > > Cheers, > > C.J. > > -- > moo. _______________________________________________ Evolution-list mailing list Evolution-list@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-list
