[Kolab-devel] Kolab 2.0 Release Coordination

[Richard Bos]

Op donderdag 8 juli 2004 18:17, schreef Martin Konold:
> Beeing able to use the provided binaries by the distribution vendors is
> extremly difficult and error prone.
>
> Look, Kolab is not only about providing the necessary binaries but also
> about makeing these binaries working together.

My comments below are from a different point of view than yours.  They'll most 
likely sound negative, but it is not meant to be negative.  On the contrary, 
please keep this in mind when reading my answers.

> 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.

And now you (not personally) make it even more difficult and very error prone, 
by not providing relocation possiblities.  Imagine that 1 day a distributor 
comes up with the crazy idea to include and integrate kolab in its 
distribution, how should they do it?  They first must _hack_ almost each and 
every kolab file to be able to relocate it.  You should be worried by this => 
it may result in a not so good kolab installation!  Even more horrifying, 
they should do this each new kolab release.  The patches for kolab-1 can not 
be used for kolab-2.  (As Mandrake has shown, it's not such a crazy idea).

> 2. Kolab provides a sophisticated method for administration of Kolab
> servers running in a clustered multi-location environment from a single
> place (e.g. 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.

Yast has no problem with this.  Once the configuration file has been altered 
by anything else than Yast, it won't be touched by Yast anymore.

> 3. The current approach allows us to support Kolab on many platforms. Due
> the the very complex nature of Kolab using many different opensource
> packages it would be impossible for us to support more than one platform
> (e.g. Debian).

Who is asking you to support multiple distributions?   You distribute the 
source the rest is up to the open source community, being the distributors or 
just people like me.  You should be willing to accept patches from those 
people of course.

> 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
> distribution vendors know their stuff much better than we dare to claim.
> Also this is the only way to prevent that updates (e.g. security updates)
> don't break existing Kolab installation. How to blame a distribution if the
> use case (using the package for Kolab) is not known to them.
>
> 5. Last but not least we believe that our approach is superiour for such a
> task. Using OpenPKG was IMHO a big success(*) sofar. The OpenPKG people
> provide excellent support and quality for us.

I consider OpenPKG as just another distribution ;)  I'm happy that OpenPKG 
delivers what you expect from it.  In case kolab is e.g. succesfull on 
Mandrake it the OpenPKG version will benefit from it as well and vice versa.

> Yours,
> -- martin
> P.S.: (*) Of course there are some aspects I am not so happy about but
> which are currently beeing worked on. OpenPKG has a track record of solving
> issues in a timely and predictable manner. E.g. more than a year ago fsl
> was a pain but it is fixed now. The static compiling causes more problems
> for me than it solves and the start/stop scripts are also not too much to
> my liking. Having apt for OpenPKG would be perfect.....
>
> 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....?

No.  See, my 1st remark (starting with 'And now you'), kolab should be 
relocatable!  Leave, the rest up to the community and accept patches 
concerning relocation.  Once kolab is relocatable distributions can start 
thinking to _integrate_ kolab into their distribution.  

--
Regards,
 
Richard


P.S. I won't be near my computer for some time.