[Kolab-devel] CVS - New Modules and Tools (releng, devel, utils)

[Stuart Bingë]

On Wednesday, 12 May 2004 17:38, Bernhard Reiter wrote:
> > I wouldn't say they belong under the server module, as these three
> > modules are not really Kolab (server) specific. These new modules are
> > designed as central places for in-development code (devel), files
> > relating to release engineering (releng) and miscellaneous utilities that
> > are used in various modules (utils) - that's why there's a 'kolab'
> > subdirectory in the devel module, as this is intended as the central
> > place for in-progess development of the Kolab server itself.
>
> But these tools are not for use on the Kolab KDE Client, the Kolab Concept
> or the webpages as far as I understood it.
> This is is the case then they would all belong under server.

OK, I'm a bit lost here :-) Tools as in the 'utils' module? Also, isn't the 
KDE Client maintained in KDE's CVS? And what exactly is the "Kolab Concept"?

With regards to the webpages, I would say they're in a decent place under 
'doc'. We could however convert the Makefile used in doc/www to a 
devtool.conf, in which case we can use devtool to manage the website as well. 

I would argue that 'utils' belongs as a separate module (at least with the 
utilities we're using now) as it is better to maintain these in a single 
location that is separate from everything else, otherwise currently we'd have 
two copies of devtool in the different releng directories (three if we start 
using it for the webpages) - this becomes irritating when you want to move to 
a new version of devtool.

Perhaps a more descriptive name for this module would have been 
'external-utils'. My intention for this module was to hold copies of the 
various external utilities that we use, such as obmtool and devtool, and any 
more that we may use in the future.

> > With this new system, I would say that ultimately we could remove the
> > server module, as all the sub-directories that are present there can go
> > into release engineering folders under releng, whereas if we're actively
> > developing portions of these modules we can create additional directories
> > under devel for them. I would say that the doc module is already in a
> > suitable place.
>
> I might not fully grasp the CVS structure then.

I could also be way off here - I don't have that much experience with project 
structure when it comes to CVS, however this system is something that works 
for us internally, and I thought it would be beneficial for Intevation's CVS 
as well.

> Usually in CVS there are Branches and tags that would mark
> development versions from stable source code lines.

Yeah, I think that's the idea.

> So within the "devel" directory there will be stable and development
> code in several CVS branches?

Correct.

> Why not call that directory "src" then?

We could do that if you want. I would say 'devel' and 'src' are interchangable 
terms.

> 	server/
> 	    src/
>             releng/
>             utils/
> seems a good structure to me.

So then the structure would basically become

    doc/
    server/
        imapd/
        ...
        src/
            kolab/
            admin/
            utils/
            releng/
                kolab/
                perl-kolab/

Correct? If that's the case, then I would say there's no need for src/ under 
server/. What about moving releng/ and utils/ up a level so they're siblings 
of src/? To me at least there should be a strict separation of files that are 
development-related, and files that relate to release engineering.

> That would include moving the admin interface under src,
> because we also want to have several branches on it, right?

Steffen would know the answer to this - I'm not sure what his ideas are with 
regards to the webclient.

> Also we want to preserve the history of the KO'LAB_1_0 branch
> so for CVS technical reason we have to think if doing
> a server2 and moving stuff in there is better to not deal
> with too much old branches in server.

Well, I can definitely see why you want to maintain server/, in terms of 
releases/taggings that have already been made. Perhaps server2/ would be a 
good idea...

> What do you think about my suggestions? 
> I am still trying to understand the structure.

That is my fault for not putting forward a suitable argument for the new 
structure. Let me try and clear it up... at least, this is the way I view it:

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.

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.

OK, what about the following:

doc/
  www/                <-- convert Makefile to devtool.conf
  ...                 <-- the other documentation modules
server/               <-- leave it as it stands now
server2/
  src/
    kolab/            <-- kolabd & kolabconf
      Kolab/          <-- the perl-kolab modules
      etc/
        kolab/        <-- This holds kolab.conf/.globals
          templates/  <-- all the templates
      var/
        kolab/        <-- (.cvsignore'd) kolab.pid & kolab.log
    admin/            <-- create a link in /kolab/var/kolab/www to this
    ...               <-- any other projects we may have
  releng/
    kolab/            <-- devtool.conf
    perl-kolab/       <-- all the Kolab-BLAH h2xs module files
external-utils/

With this system, we can set the kolab root 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.

> We should start a webpage with it.

Good idea.

A bit OT - relating to the website... are there any plans to merge the content 
on kolab.org and kroupware.org into a single hierarchy on kolab.org? Or is 
there a specific reason that the two separate websites exist separately?

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