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

[Steffen Hansen]

On Thursday 13 May 2004 12:39, Stuart Bingë wrote:

[...]
> 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

Yes, I fully understand that point. But it is only valid if it runs as 
smoothly as if the perl modules were installed under /kolab.

[...]
> 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.

With the old (Makefile based) system, I just edited the templates etc. 
in /kolab and when they all worked, I copied them back to the CVS 
controlled dir and did a search'n'replace on /kolab => @l_prefix@ etc. 
When editing perl-code I did something similar. It was not a high-tech 
solution, but it worked, so it is no big deal.

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

^ that would be the website, right?

> 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

^ the rpm spec-files for the packages should also be in releng. I really 
want to be able to make an rpm whenever I like it to be able to copy it 
from my development box to my test box and see if everything works. 
That must be possible without devtool starts messing with version 
numbers, start tagging or modifying CVS or anything like that.

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

That sounds like a good idea.

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

This sounds fine to me. I don't care much how it works, as long as it 
works at all and is easy to set up and use, and in particular it has to 
work for me :-)

regards
-- 
Steffen Hansen          |       Klarälvdalens Datakonsult AB
Senior Software Engineer|       http://www.klaralvdalens-datakonsult.se
                        |
                        |       Platform-independent
                        |       software solutions