[Kolab-devel] Kolab release confusion

[Stuart Bingë]

Hello all,

A rather embarrassing question, however I felt it necessary to ask in the hope 
that it would not only clear the situation up for me but for others who are 
also perplexed by the confusion :-)

The problem is basically that I'm not entirely sure of the way that the Kolab 
source code on Intevation's CVS server, ZfOS and OpenPKG interoperate with 
regards to Kolab releases.

As I'm currently in the process of reorganising Intevation's CVS into a more 
intuitive system (whereby development- and release engineering-related work 
are separated, as was discussed on the list previously) I'm also trying to 
integrate Ralf Engelschall's excellent 'devtool' utility that Thomas 
submitted to the old kroupware list on the 28th of January, which seemed to 
slip through the cracks. As a few of the files in CVS relate to release 
engineering I'm not sure whether to include them, or indeed where would be 
the more 'correct' place for them to reside.

The files in question would be obmtool.conf, rc.kolab, the RPM spec files and 
Makefiles for kolab and perl-kolab. The question is whether I need keep them 
on Intevation's CVS server, whether they can be removed, or whether or not 
they belong elsewhere.

Firstly; are these spec files the authoritative specs that OpenPKG use when 
building the kolab and perl-kolab RPMs? I'm assuming not, and that OpenPKG 
have their own specs kept in OpenPKG CVS - if so, can we remove them?

Secondly; how do the various versions of obmtool.conf found all over 
Intevation's CVS and ZfOS's FTP server relate? Which one would be considered 
authoritative?

Thirdly; is the rc.kolab file on Intevation's CVS server the actual RC script 
that OpenPKG use for the Kolab RPM, or does OpenPKG maintain their own 
version? Do we need to keep this file?

And lastly; the various Makefile's in the kolab and perl-kolab directories - 
are these only used to ease testing, in that a test RPM can easily be built 
and installed while developing? If this is the case then I think it would 
make more sense to move this functionality into the devtool, so that there is 
a single process to both build proper releases and test builds. This may not 
even be necessary with the new structure, as if you wish to develop and test 
all you need do is check out the 'devel' module and start using the code in 
that directory.

Once the new system is in place (and assuming everyone is happy with it and 
actually uses it), this is how I would see the new release process:

- Check out the 'devel' and 'releng' modules from Intevation's CVS
- Run './devtool release' in releng/kolab, which will update devtool's 
version.pm to correspond to the new release version number. This process will 
include automatically copying the source files in 'devel' to their proper 
release locations in the current releng directory, while at the same time 
substituting any necessary variables (for example, any occurrences of 
'/kolab' will be replaced with '@l_prefix@').
- Upload the release tarball to ftp.kolab.org (or CPAN in the case of 
perl-kolab) where OpenPKG will pick it up and create an updated RPM in 
OpenPKG-current. (Will the authoritative tarball repository be ftp.kolab.org, 
or ZfOS?)
- Check-in the updated version.pm file back to Intevation's CVS.

As an aside; if you have any questions about the new CVS process I'll be more 
than happy to answer them for you.

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/