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

[Helge Hess]

Tony Clayton wrote:
> I haven't been following the evolution of gstep-make, so I wasn't
> aware of any instability.

Don't get me wrong on this. I don't mean instability with regards to 
running makefiles.

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

Yes. At SKYRIX we use a new CVS module for each version. I never used 
CVS branches.

But tags should work just fine on subtrees of a module?

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

Check the mailing list about "separate" packages. People don't like it, 
and while we have RedCarpet and apt for binary packages, we have no such 
thing for CVS.
Developers should get everything required by a single "cvs checkout", 
IMHO ;-)

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

I referred to *our* automatic build process.

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

We want to maintain OGo, not GNUstep. gstep-make only is in OGo CVS 
because it makes the OGo maintenance job easier.

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

We could, but it would make it harder for us and it's already hard 
enough. We are not going to complicate processes without reason.

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

The day GNUstep will provide stable packages, we'll do. We do not want 
to provide own packages, this is an unfortunate requirement. And IMHO 
it's the job of GNUstep to improve on that if they want to participate, 
not the one of OGo.

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

We did make some changes, but mostly for deployment.

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

Well, OGo is a development project, not a distribution project. I 
absolutely agree that Linux distributions will come up with their own, 
optimized packaging of OGo.

regards,
   Helge