FOSDEM 2007 Developer Workshop

From GNUstepWiki
Revision as of 20:09, 5 March 2007 by Kokosmakrone (talk | contribs)
Jump to navigation Jump to search

What to do with 3rd Party Solutions within the GNUstep Community?

This page contains the original abstract and the summary of results of the developer workshop. The workshop took place on saturday, 24th of march.

Abstract

The goal of this workshop is to discuss questions dealing with 3rd party solutions and GNUstep and to summarize the results. At the beginning we may identify projects which seem to reinvent the wheel. Such projects are those implementing add-ons which have been developed before - logging functionality is a good example for this. Also, we may focus projects (re-) implementing GNUstep base functionality, like e.g. mySTEP. Then, having these projects figured out we may elaborate the potential reasons behind.

By starting to identify reasons for "duplicating" code we may shift the discussion to a different perspective and ask ourself, what GNUstep brings to the application programmer? Especially we may work out the requirements of the "typical" GNUstep application programmer. Collecting all information, thus bringing the potential reasons for "duplicated" codes, plus the capabilities of and the requirements for GNUstep altogether, we may then find out approaches for the handling of 3rd party solutions within the GNUstep community.

Since this session is meant as a workshop, the abstract presented hereby should be regarded as a collection of hints and all developers are warmly invited to actively participate in the discussion. The session will be moderated and organized by Helge Hess and Oliver Langer.

Moderation: Helge Hess, Oliver Langer

Schedule: 2 hours


What we did

We identified projects which have the same or similar goals at least. As a result a list of subjects with their related projects has been worked out. Based on this list we wrote down potential reasons for these duplicates. Next we tried to find some solutions to resolve some duplicates.

Find below the list of duplicates, issues and solutions. As expected, we were far away from having all and complete solutions.

Results

List of projects

Subject Related Projects
ObjCRuntime AppleRuntime, GNU Runtime, Cocotron, (David)
Foundation libFoundation, gstep-base, Cocoa, myStep, Cocotron, mgStep, SideStep
AppKi gstep-gui, Apple, Cocotron, myStep, mgStep, (SideStep)
Mime gstep-base, sope-mine, Pantomine, EDMessage, MailCore
XML gstep-base, Sope-XML, Cocoa
Database SQLClient, EDL2, sope-gdl1, CoreData, MulleEOF, BDB, FT
Web gstep-web, Web-Server, SOPE, myStep
Logging (gstep-base), Encore, sope-core, (Brainstorm), Log4Cocoa

Reasons for Duplicates

We identified the following reasons:

  • License
  • NIH
  • Historical not available
  • Quality
  • Code sucks
  • Stability
  • Coding style
  • Copyright assignment
  • Communication
  • Information
  • Parallel work
  • Not asking for existing solutions
  • Design decisions
  • Incompleteness
  • Deployment

Additionally we identified:

  • Many links are broken on the website
  • No public access for wiki
  • With ObjectiveC 2.0 the runtime will not be compatible to Apple.

Reasons wrt. to subjects/projects:

  • ObjCRuntime
    • Projects underly different licenses
  • myStep
    • historical
    • Different goals

Due to limited time we were not able to work out the reasons for the other duplicates. We found out that in a lot of cases communication seems to be the major lack. E.g. people don't ask for existing solutions or for issues they have with a certain piece of software; finding related information on the web seems to be an issue as well.

Solutions

Solutions being stated:

  • libFoundation team is willing to merge their project with gnustep
  • myStep team is putting efforts in merging/exchanging (at least partially) with gnustep

Ideas mentioned for handling such merges:

  • the projects should use branches in the same repository.
  • gnustep is willing to share its repository
  • code is merged step by step from branch to branch

Additional solutions we worked out:

  • Better quality through reusage
  • Use common repositories for similar projects and migrate step by step
  • Steps/Approaches (project plans, issues with existing software et cetera) should be communicated
  • Use Wiki as a central point for announcements and discussions
  • Wiki of CocoDev works fine and may be a good reference
  • Push more and more to the Wiki and only the musts on the GS web site
  • Write the goals of GS and the differences to other projects for the public