[Kolab-devel] [Proposal] New CVS Structure (again)
Stuart Bingë
omicron-list at mighty.co.za
Sat May 15 09:10:01 CEST 2004
On Saturday, 15 May 2004 01:03, Steffen Hansen wrote:
> How about the perl-kolab code if we keep the current server/ CVS module?
> The stuff in there was imported from the newest available package at
> the time we started hacking on it + my (relatively few, but to us
> important) changes. I fear that if the CVS structure does not suit your
> need also, you will develop your perl-kolab package elsewhere and we
> will not mutually benefit from improvements unless we burden ourselves
> with merging changes in often. How do we make sure that this works out?
Does the current CVS code contain the fixes (or code equivalent to the fixes)
that have recently been made to combat the incorrect slapd.conf permission
problem? If so then the CVS code should be as up to date as needs be.
Again, the only major change we have now integrated is the metadata template
system. There are also a couple of small things, such as slightly improved
kolabconf and kolabd scripts, as well as renaming some of the configuration
variables to hopefully more meaningful names ($config{'prefix'} =>
$config{'kolab_root'} is one example). The version of kolabconf/kolabd in the
devel module can load configuration files from the command line (if you wish
to override loading .globals/.conf) and kolabconf is able to do stdio
configuration substitution - this was in preparation of the new bootstrap
system that we planned to implement.
With the new template system Conf.pm is no longer needed (at least in the
version that we are using). The template handling code was basically
rewritten and moved to Templates.pm - unfortunately there were certain things
that we abandoned in this move as we never used them/could not see where they
were used. Examples of these are the buildPostfixTransportMap(),
buildCyrusConfig() and buildCyrusGroups() functions. buildCyrusConfig() has
effectively been moved to the new template/new configuration variable system,
so the separate function is no longer needed, however there are no
equivalents in the current code of the other two functions that were removed.
If people would be interested in any of these changes appearing in the server
module's code I can merge them in. The only problem with this is there are
some pretty fundamental changes to the code (such as renaming configuration
variables) that may very well break something for someone who closely relies
on the current structure. Perhaps it would be best to leave this until,
again, there are no urgent deadlines to meet, and we have the time to
properly integrate everything.
> How do you feel about using IRC for low-latency communication btw? I
> will hang around on #kolab on freenode.net in case anyone wants to join
> in and talk.
Good idea. I think most of us are on or around GMT+2 so IRC would work out
quite nicely. I will most probably join you next week.
Regards,
--
Stuart Bingë
Code Fusion cc.
Office: +27 11 673 0411
Mobile: +27 83 298 9727
Email: s.binge at codefusion.co.za
Tailored email solutions; Kolab specialists.
http://www.codefusion.co.za/
More information about the devel
mailing list