FOSDEM 2007 Developer Workshop
|Revision as of 01:59, 6 March 2007
Martin (Talk | contribs)
Reasons for Duplicates
← Previous diff
|Revision as of 02:00, 6 March 2007
Martin (Talk | contribs)
Next diff →
|Line 93:||Line 93:|
|* Steps/Approaches (project plans, issues with existing software et cetera) should be communicated||* Steps/Approaches (project plans, issues with existing software et cetera) should be communicated|
|* Use Wiki as a central point for announcements and discussions||* Use Wiki as a central point for announcements and discussions|
|-||* Wiki of CocoDev works fine and may be a good reference||+||* Wiki of [http://www.cocoadev.com/ CocoaDev] works fine and may be a good reference|
|* Push more and more to the Wiki and only the musts on the GS web site||* 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||* Write the goals of GS and the differences to other projects for the public|
Revision as of 02:00, 6 March 2007
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.
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.
List of 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:
- Historical not available
- Code sucks
- Coding style
- Copyright assignment
- Parallel work
- Not asking for existing solutions
- Design decisions
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:
- Projects underly different licenses
- 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 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 CocoaDev 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