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

[Nicola Pero]

> > The original reason for the discussion is that the GNUstep-reset.sh script
> > in OGo's gnustep-make was reported not to work - a patch to fix it was
> > provided.
> 
> I volunteer to make that patch. Takes me 5 minutes [...]

But you shouldn't be spending your time maintaining an old version of
gnustep-make and writing again code which has already been written - not
even 5 minutes!  And of course your version will be different from the one
used on the main trunk, and next time you try to upgrade your own
gnustep-make version you'll have to spend a lot of time trying to merge
the two.  That's just wasting time.  You should be spending your time on
OGo, not on these tasks!

Maybe you should/could make a difference between what you ship as part of
Skyrix and what you ship as part of OGo.

It seems that your points about commercial support and very stable
releases make mostly sense for Skyrix as a business, shipping and
supporting your customers.  Of course you can ship and support whatever
version of gnustep-make you want and whatever is most appropriate for your
business.  If you find 1.3.3 is a very stable release, go on with that (at
brainstorm we find that 1.7.2 is a very stable release, more stable than
1.3.3, so that's what we use).

But other OGo users/developers should really be working with the latest
gnustep-make, and patching the latest gnustep-make when they find
problems.

For example, porting to other platforms (Windows, Apple, etc) is probably
an interesting task for an OGo developer.

And compared to 1.3.3, the latest gnustep-make includes a lot of work on
native Apple and Windows support for example.  It doesn't make any sense
to work on porting to such platforms basing your work on 1.3.3 - of course
you should use the latest release.

Btw, one reason why it takes you so long to upgrade to a new gnustep-make
is that you do it so rarely.  It's more than one year you don't upgrade
:-)

The other reason is that you patch it, and never contribute those patches
back to the main trunk, so you end up with a gnustep-make which is no
longer even 1.3.3, but it's something different, and then of course
updating to 1.7.2 is really a merge process of two different branches, and
requires work to manually check every single patch and every single line.


 
> > But I don't see why we should be wasting time patching an old 
> > gnustep-make
> > 1.3.3 rather than simply using gnustep-make 1.7.2 where the script has
> > already been fixed ... a couple of releases ago! :-)
> 
> Because this is proven to be stable for quite a wide range of systems 
> and a packaging process exists which works fine with exactly that 
> version.
> Did you test gstep-make 1.7.2 on SuSE 6.2 or RedHat 6? What about Sun 
> Cobalt Linux?

I didn't test those platforms myself.

But GNUstep users are testing it on all platforms they are using, the
range of which is wider than the platforms you list here.  Quite a lot of
platforms, including many unix variants, *bsd, windows, apple, linux on
ppc etc.  You could add the platforms you test on to the pot, and we'd get
an even better product, tested on even more platforms.


> Is the experience of the SKYRIX staff still valid with the new release
> or what tweaks are introduced?

You are right in talking of the SKYRIX staff.  My recommendation would be
to ship whatever version you are comfortable with as part of your SKYRIX
package, while letting free software developers/users play and tweak with
the latest versions - so that they iron out and solve the problems for you
*before* you ship it commercially!

I'm not arguing that you should upgrade your own SKYRIX packages to the
latest gnustep-make now.  I'm arguing you should encourage OGo developers
to use the latest gnustep-make so that they test stuff, find problems, and
patch both OGo and gnustep-make to make it all work in harmony together.  
Then once all that reaches a stable state you can upgrade all your SKYRIX
packages to the latest release, and it should take little effort.


At the end of the day, I'm just trying to have gnustep-make maintained in
a single place rather than in two places, because I think that it is a
much more efficient and effective way of maintaining it.  I'm open to
discuss including OGo's specific patches in gnustep-make, or testing
gnustep-make releases against OGo before release to make sure gnustep-make
releases work with OGo, or any other measure which can help making the two
projects work together.