[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