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

[Stuart Bingë]

On Thursday, 13 May 2004 15:51, Steffen Hansen wrote:
> 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.

Well, your system works - it's not exactly optimal, however it has its 
advantages. Hopefully we can reach a system where this manual work is not 
necessary, and we have tools that handle all the code transformations needed 
for a release.

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

Yes. Bernhard gave reasons for moving this up a level in the 'CVS - New 
Modules and Tools' thread.

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

Agreed - spec files relate to release engineering, so they would belong in 
releng.

The only problem I have with this is synchronisation between our spec files 
and the ones OpenPKG use to build the actual packages. As far as I 
understand, the kolab.spec file maintained in OpenPKG CVS is considered 
authoritative, however, this does become a problem when, like we're currently 
doing, we start moving files around and subsequently need to update the spec1 
files.

I'll add the spec files in, however I definitely think we should clarify the 
relationship between ours and OpenPKG's. Primarily I would like us to resolve 
all the versioning nightmares we've experienced in the past, and this is 
where I thought using devtool with tarball releases would help. Clearly I 
misunderstood this whole issue, however.

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

OK. If no-one raises any concerns before tomorrow, Fri May 14, 13h00 UTC I'll 
implement this new structure I have described, including adding in the spec 
files and updating devtool.conf to allow for building RPMs.

Cheers,

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