[Kolab-devel] [Proposal] New CVS Structure (again)
Stuart Bingë
omicron-list at mighty.co.za
Thu May 13 17:20:35 CEST 2004
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/
More information about the devel
mailing list