Re: Was GNUstep ready for GNUstep ?

[Tim McIntosh]

On Apr 29, 2007, at 1:45 PM, Stefan Bidigaray wrote:

On 4/29/07, Tim McIntosh <tmcintos@avalon.net> wrote:

This is only a half baked idea, but it seems like it would be nice to have a summary table on the wiki (or somewhere) for each core release that included the following information for all applications and frameworks:

Package Name

Latest Version

Release Date

Primary Maintainer (None if package is not actively maintained)

Verified Working With This Core Release? (Yes/No)

Platforms Tested

I agree with Andrew on this one... who's going to maintain this list?  That's double the trouble for half the results!  Like I said, in my opinion, it has to be the package maintainer's responsibility to catalog what version of GNUstep-core his application requires seeing as he/she would be the only one that knows what classes/methods the code requires off the top of his head, not to mention they would have tested the code before release.

Seeing as GNUstep still doesn't have a 1.0 release, I think the backward incompatibility is even more important!  At this point, there should be no worries about who's code the next release is going to break.  However, once a 1.0 release is announced, I think all 1.x code should be not only API compatible but also ABI compatible (that is, mostly bug fixes).  This is a conversation for another day though, and kind of diverges from the current subject. 

I agree that this isn't something that any single person would want to (or be able to) maintain in its entirety;  I wasn't suggesting that.  I was thinking it would be appropriate for something like the wiki or some other form of database that could be continuously updated by anyone in the community.  There is already a list of applications on the wiki;  perhaps the above information could be added to the existing pages (in cases where it's not already there) and then periodically automatically extracted and compiled into the sort of table proposed above?

I agree that backward compatibility with previous GNUstep releases should be considered low priority at this point.  It seems to me that anything that would help newcomers quickly pull together a usable GNUstep system should be considered high priority right now.

I have been following GNUstep for 10 years now, hoping to see it gain some traction and looking for a way to contribute.  About once a year I get the itch to try to port some of my OS X projects to GNUstep, or to look for an existing GNUstep app that I could contribute to.  I typically invest around 40-100 hours trying to build a coherent GNUstep development environment (usually based on FreeBSD) including core frameworks, user applications, and development applications,  before ultimately giving up in frustration.

One of the hurdles for me is always locating and sorting out the "flagship" applications from the unusable ones.  The table proposed above was intended to provide an aid for this task.  Without digressing too far here, other typical hurdles are: figuring out how GWorkspace and WindowMaker are intended to be used together, the lack of a usable development environment (mostly talking about Project Center here - Gorm is looking good) and incompatibility of most GNUstep apps with OS X, due to dependencies on GNUstep-specific extensions (for example, I may look into fixing some of the problems I have with Project Center if I could build and debug it under Xcode;  and the same goes for CodeEditor.app).

I don't mean to offend anyone here--I want GNUstep to succeed.  I'm just not sure this is going to happen without a change in priorities, especially considering how things like GNOME have apparently overtaken GS in the last 10 years.

-Tim