[Kolab-devel] thomas: server/php-kolab/Kolab_Filter issue3192.patch, NONE, 1.1 issue3441.patch, NONE, 1.1 ChangeLog, 1.28, 1.29 Kolab_Filter.spec, 1.18, 1.19 Makefile, 1.7, 1.8

[Gunnar Wrobel]

Quoting Richard Bos <ml at radoeka.nl>:

> Hi!
>
> Op woensdag 04 maart 2009 10:09:41 schreef Thomas Arendsen Hein:
>> > - will those patches be available via the packages kolab-filter [1] and
>> > kolab- freebusy [2] on pear.horde.org?  If so, when will they be
>> > available?
>>
>> Gunnar is quite busy at the moment, but I expect those patches to go
>> upstream in the preparations for 2.2.1 final (together with unit
>> tests).
>
> The unit tests have already proved to be useful (at least for me)!   
> That's why
> I found the incorrect version of the iCalendar package.  As a side effect I
> learned that the horde package is not at all necessary for the plain kolab-
> server.

As mentioned before I hope to be able to add tests soon that check a  
real, configured server. This should again help to improve native  
installs (as well as giving us some simple checks when preparing the  
next release).

>
> BTW: how to deal with the horde packages in case the kolab server and the
> webclient are installed and run on 1 server?  In this setup the kolab server
> must use the package in  (e.g.) /usr/share/php5/pear directory, while the web
> client should use the horde packages in /srv/www/htdocs/horde/lib
> As the include path is defined in /etc/php.ini should there be 2  
> php.ini files
> 1 for the kolab server and another to be used by the web client?

The webclient is fully self contained. It does not need anything in  
/usr/share/php5 or /usr/share/php5/pear. It solely needs the PEAR  
packages within the "lib" directory and the "pear" directory. As long  
as you have an apache server and php5 patched for Kolab you can  
install it and need nothing else.

This approach has its advantages and disadvantages. You can simply  
take the package and install it anywhere. You can also easily migrate  
the whole package from one location to another. The main reason why I  
chose to use the horde-webmail package - which comes with this type of  
arrangement - as base for the kolab web client was that the package is  
well separated from the rest of Kolab and can also be easily installed  
on an external server.

On the other hand you get this dreadful code duplication which is  
pretty bad from a technical perspective. So I'll slightly change the  
installation of the web client after Kolab server 2.2.1 so that we get  
the best of both worlds.

>
>
>> > Why are the patches applied against the rpms, and not upstream (no
>> > offence, just curious)?
>>
>> Some moments ago we were upstream, but as this has changed I do not
>> have commit access[1] to their repositories. So the only chance to
>> get in changes fast is to use patches.
>
> ok.
>
>> These patches are not applied
>> against the RPM, but against the included unmodified upstream
>> tarball, so you might be able integrate them in your RPMs, too.
>
> That's what I actually meant with applied against the rpm (of course they are
> applied against unmodified upstream tarball).  I'll wait for you, hopefully
> you can commit the changes soon to upstream.

I'll work on getting the patches upstream today.

Concerning the PHP code of the Kolab server you can always count on  
getting the latest code from horde.org. At least as long as the code  
is under my control :)

Having stuff upstream is very important to me as I do get all the  
infrastructure for decent source releases there which we don't have  
(or didn't establish) on kolab.org. As this is relevant for supporting  
the native installations I want to keep it that way.

Of course this is problematic for Thomas when he wants to release the  
next Kolab server version and needs a hotfix for something. Currently  
I just lacked the time to polish the patches for upstream inclusion  
but for situations where we have just a single bugfix on a package I  
might not always immediately release a new version upstream.

Cheers,

Gunnar

>
>> Thomas
>>
>> [1] I haven't tried to get commit access as they are currently
>> moving from CVS to git including at least two important branches in
>> each SCM that have to be kept in sync. I'll wait until things settle
>> down before trying.
>
> Interesting, also moving to git.....

For everyone interested the link to my current repository  
https://github.com/wrobel

The stuff is not documented (yet).

"horde-release" is the Kolab web client development.
"horde-fw3" is the branch that is considered stable at the moment.
"horde" is the Horde git HEAD branch that will become Horde 4
"horde-cvs" is the Horde CVS HEAD branch that will get deprecated once  
everything moved to git
"horde-hatchery" is the experimental Horde area in git

For bleeding edge Kolab related stuff:

  - Branch "t/KOLAB" within "horde-release" is the newest Kolab web client
  - "horde" will see the Kolab_* PEAR packages rewritten for PHP5  
soon. Currently
    you can watch me restructuring and preparing Kolab_Server for  
Horde 4 there.
  - "horde-hatchery" will see a new Kolab web admin based on Horde 4 soon.

Cheers,

Gunnar


>
> --
> Richard
>
> _______________________________________________
> Kolab-devel mailing list
> Kolab-devel at kolab.org
> https://kolab.org/mailman/listinfo/kolab-devel
>



-- 
______ http://kdab.com _______________ http://kolab-konsortium.com _

p at rdus Kolab work is funded in part by KDAB and the Kolab Konsortium

____ http://www.pardus.de _________________ http://gunnarwrobel.de _
E-mail : p at rdus.de                                 Dr. Gunnar Wrobel
Tel.   : +49 700 6245 0000                          Bundesstrasse 29
Fax    : +49 721 1513 52322                          D-20146 Hamburg
--------------------------------------------------------------------
    >> Mail at ease - Rent a kolab groupware server at p at rdus <<
--------------------------------------------------------------------


----------------------------------------------------------------
This message was sent using IMP, the Internet Messaging Program.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: Digitale PGP-Unterschrift
URL: <http://lists.kolab.org/pipermail/devel/attachments/20090305/7fd331ae/attachment.sig>