On Apr 29, 2007, at 1:45 PM, Stefan Bidigaray wrote:
On 4/29/07, Tim McIntosh <[EMAIL PROTECTED]> 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
_______________________________________________
Discuss-gnustep mailing list
[email protected]
http://lists.gnu.org/mailman/listinfo/discuss-gnustep
