[Kolab-devel] Kolab 2.0 Release Coordination

[Jean-Michel Dault]

Le jeu 08/07/2004 à 12:17, Martin Konold a écrit :
> Beeing able to use the provided binaries by the distribution vendors is 
> extremly difficult and error prone.

It shouldn't be.

> 1. All binaries must match the Kolab requirements with regards to versions, 
> compile time options and features (e.g. some binaries require a Kolab 
> specific patch). The requirements of Kolab are not met in every respect by 
> the distribution vendors.

- OpenLDAP has not been modified. It can work with or without SASL
support (I haven't seen bi-directional dependencies in years)
- Cyrus-SASL: LDAP support might be experimental, but most distros have
it enabled
- Postfix: no modifications
- Cyrus-imap: all the patches you apply should be merged upstream, as
they apply to every distro. The only kolab-specific patch is the group
patch, and it's currently not applied in Mandrake, because we're looking
to put the groups in LDAP.
- Postfix: most distros should have LDAP support
- Apache: most distros include LDAP and DAV support

So, it shouldn't be an issue, all the options Kolab needs should be
included by default in all distributions.

It might take some time, and I agree with you that OpenPKG is the best
way *for the moment*, but if we want Kolab to be *the* reference in
groupware, it *has* to come standard with Linux distros.

> the Kolab WebGUI). Kolab depends very heavily on storing the configuration in 
> a LDAP repository. This approach is very different from the distribution 
> specific technologies of the day e.g. YaST2 or linuxconf.

Kolab should be compatible with existing LDAP setups, it does not make
major modifications apart from the schema and replication.

> 4. It is the job of the distribution vendors to integrate OSS into their 
> offerings. E.g. Mandrake did a very good job in this for Kolab 1.0. The 

Well, Mandrake has integrated it, but there's still some issues to be
resolved, but I'm working on it.
> 
> P.P.S.: Richard: Would it help you if we would roll a complete Kolab 
> installation in a single big rpm/dpkg and then simply conflict with existing 
> httpd, smtpd....?

This is the worst thing that we could do.

If we want Kolab to dominate the market, we must each work together to
resolve these issues. Me might not be ready, and OpenPKG might be the
best solution so far, but eventually, the whole thing needs to be
commoditized.

-- 
Jean-Michel Dault <jmdault at mandrakesoft.com>