[Kolab-devel] Kolab 2.0 Release Coordination
radoeka at xs4all.nl
Sat Jul 10 21:39:51 CEST 2004
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.
> -- 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.
P.S. I won't be near my computer for some time.
More information about the devel