[OGo-GNUstep-Port] Re: gstep-make upgrade

[Tony Clayton]

On Mon, Jul 28, 2003 at 09:38:53PM +0200, Helge Hess <helge.hess@opengroupware.org> wrote:

> Personally I also do not have the impression that this is really 
> necessary, the gstep-make in OGo works just fine and smaller backward 
> patches are easy to do. I rather do that instead of tracking a version 
> all the time.

I haven't been following the evolution of gstep-make, so I wasn't
aware of any instability.

> >- create a separate cvs module for each third-party package (like
> >		gstep-make)
> 
> Hm, why? What additional values is given to you by a separate CVS 
> module? We also thought about that prior setting up OGo CVS, but 
> couldn't find a reason for not using the same CVS module.

IMHO, separate modules makes things alot easier if/when you are using
tags and branches.  You mentioned earlier in a separate thread that at
some point you would have a build manager responsible for versioning
and releasing snapshots.  I find that tags are indispensible for
managing release cycles in CVS, and branches are often useful as well
for stable/devel stream forking.

I suppose you can tag subdirectories in a module separately, but you
definately don't want to mess up.  Separate modules are also easier if
you only want to work on one piece; you don't have to wait forever to
check in/out the whole module.
 
> 
> >- import and tag the pristine sources with the third-party versions
> 
> We track changes in the ChangeLog or ChangeLog.skyrix (could be renamed 
> to ChangeLog.OGo), if the project already has one.

Sure, in a fuzzy way.  And you could always do a big diff against the
original tarball to find the complete set of changes.  But for each
individual change, the "why" is often lost.  However, if you cvs-tag
all related patches together, you retain the "why" for each individual
change.  An easy way to do this is to include the cvs tag in the
Changelog comment. 

> Packaging isn't related to that at all. The RPM/Deb building is based 
> on .tgz archives which do not need to come out of CVS.

Actually, RPM/Deb is based on .tgz archives (aka pristine sources),
plus any patches to those sources.  The pristine source in this case
is actually the gnustep-make tarball from the GNUstep project, which
gets lost in OGo CVS currently.  

So, I'm saying rather than releasing
opengroupware.org-gstep-make-XXX.tar.gz, you could release the
pristine gnustep-make-X.Y.Z.tar.gz tarball, along with any source
patches from OGo (which can easily be pulled from CVS via tags).  
The RPM/Deb packagers can then grab the tarball from GNUstep, and add
your patches.  At the same time, you could submit one or more of the
patches back to the third-party project (ie: GNUstep) if you want.  

Of course, you can then also distribute an OGo tarball with the
pristine tarball, patches, and a build script.  

> Again, I don't think anything really needs to be "ported" to 
> gstep-make, it should work pretty much out of the box. If you find 
> issues, let me know ;-)

Ok.  I was under the impression that OGo had added changes to the
gnustep-make sources and re-released it.  Either way it shouldn't be
too difficult - assuming the magic variables in the make process
haven't changed ;-)

I've found the above practice to be quite affective for managing large
projects (ie: a linux distribution) with third-party sources and
multiple developers (and with the appropriate development scripts to
aid, of course).


cheers,

Tony