[Kolab-devel] [Proposal] New CVS Structure (again)

[Stuart Bingë]

This issue has been discussed quite a bit lately, and I've come to the 
conclusion that the new devel/releng system I implemented a couple of days 
ago as the new CVS structure is not good enough for what we need. Most people 
seem to have problems getting up and running with it, and others would like 
it changed.

Based on these issues I propose to change it again, once and for all; however 
I would like to hear from everyone as to whether this new way would be 
useful/usable, or whether a completely different system would suit the 
project better.

This is basically a copy-n-paste from a reply of mine to the "[Kolab-devel] 
CVS - New Modules and Tools (releng, devel, utils)" thread.

First, an argument as to why I think the devel/releng structure is beneficial.

The development directories (devel or src) hold code that is structured so 
that a user can check the modules out and start hacking/running them 
immediately (assuming the code isn't broken at the time). The release 
engineering directories are structured so that users can check them out and 
easily build a release, by running make or by using devtool.

Each subdirectory of releng/ then corresponds to a separate package (in our 
case, kolab and perl-kolab, and other stuff that we can add such as Smarty, 
etc). Releng packages are separate from one another, as they each have 
different build requirements and files from one package must never appear in 
another (packages never overlap). This is the case currently with all the 
subdirectories under server/ - each of these is a separate package, and you 
would never think of merging two of these.

This becomes an issue with our Perl code, as we have several modules that are 
distributed as the perl-kolab package, and of course on which the engine 
itself relies. If you want to check out the engine and develop on it, as well 
as test/run it, you're going to need the perl-kolab modules.

Now, I'm sure that when you're coding and you modify a perl-kolab module, you 
definitely DO NOT want to have to rebuild the perl module's dist tarball, 
roll a new perl-kolab source rpm and finally upgrade your existing Kolab's 
perl-kolab package with the new one, just to test your new change. This is 
why I moved everything into a development directory, which contains the 
daemon and configuration executables themselves, and also has the perl-kolab 
modules in the correct directory structure so that Perl can read them (out of 
the current directory) - this then (almost) satisfies the criterion of being 
able to check out the code and immediately start running it.

Describing the problems with the system I recently implemented:

I say almost as there are also data files in the release engineering 
directories that that daemon requires in order to run, such as the templates 
and configuration files. This is actually the biggest flaw with the new 
system I put in place, as currently you are required to have the kolab 
OpenPKG rpm in place so that the code you're developing on in your devel 
checkout can actually run. This becomes a problem when you want to modify 
your data files, as you have to manually copy them over.

This is what I propose as the new structure:

doc/                  <-- as it is now
  ...                 <-- the other documentation modules
www/                  <-- moved up a level (Bernhard's suggestion)
server/               <-- leave it as it stands now
server2/              <-- becomes the base for the Kolab2 code
  src/                <-- CODE REPOSITORY
    kolab/            <-- kolabd & kolabconf
      Kolab/          <-- the perl-kolab .pm modules
      etc/
        kolab/        <-- This holds kolab.conf/.globals, etc
          templates/  <-- all the meta-enabled templates
      var/
        kolab/        <-- (.cvsignore'd) kolab.pid & kolab.log
    admin/            <-- the new admin interface
    ...               <-- any other projects we may have
  releng/             <-- RELEASE ENGINEERING REPOSITORY
    kolab/            <-- devtool.conf to build a Kolab tarball
    perl-kolab/       <-- all the Kolab-BLAH h2xs module files
    admin/            <?? if we want to split off the admin interface
external-utils/       <-- holds devtool/obmtool, etc.

server2/src/kolab basically becomes a development mirror of /kolab, however it 
is completely separate from your /kolab hierarchy, and is set up in such a 
way so that all code is easily accessible, and you don't need to keep on 
re-installing perl modules when you want to test your changes.

With this system, when you want to do coding & testing, you can just set the 
kolab root in all relevent files in the server2/src/kolab module to be '.', 
and the code will then reference all the 'in-development' data files that you 
are using, out of the current directory. The templates will still have their 
'location' field set to their proper destination under /kolab so that you can 
actually test your changes fairly easily using your existing /kolab 
hierarchy.

server2/releng/kolab basically then becomes a repository for the devtool.conf 
that is used to build a kolab release tarball. This will then archive up the 
daemon, utility scripts, and data files from server2/kolab, while at the same 
time performing the necessary transformations ('.' -> @l_prefix@, etc) and 
moving them into their release locations within the tarball.

server2/releng/perl-kolab will be very similar to what releng/perl-kolab is 
now, holding all the h2xs-generated perl module files as these directly 
relate to release engineering of the package. When building a release from 
here it will copy & transform the perl modules from server2/src/kolab.

Within each releng/XXX project directory we can then edit the devtool.conf to 
allow for creating both release tarballs and development source RPMs.

So, what does everyone have to say about this?

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