At the moment (November 2005) there are two persons involved in the active development of this extension. We're looking for others to help us on working on this extension. If you'd like to contribute, please read the section “Helping out” in this document.
Oliver KleeThe inventor of this extension who is the chief developer. Oliver keeps track of the roadmap, the global direction of the extension and provides the most new functionality and bug fixes.
Mario RimannJoined the team in October 2005 and is involved in planning the new back end, writing documentation and provide bugfixes.
We have a page in the TYPO3 wiki for storing texts, drafts an other stuff.
The former development mailing list for this extension has been closed due to low traffic. We can use the “normal” mailing list on lists.netfielders.de for talking about development. If you are interested in joining the team, please contact Oliver.
If you want to change the extension itself, it is highly recommended to contact the developers and contribute your changes back to the project. This has several advantages:
You can still get further updates of the extension without having to apply your changes again.
The extension developers can help you integrate your code better with the other parts of the extension.
Other users of the extension can benefit from your contributions.
To always have the latest and greatest version of this extension for development, please get the files from the SourceForge.net Subversion (SVN). These are the access parameters as entered in Eclipse:
Connection type | https |
User | your SF.net user name (only needed if you want to commit any changes) |
Password | your SF.net password (only needed if you want to commit any changes) |
Host | svn.sourceforge.net |
Repository Path | /svnroot/typo3xdev/ |
Module name | tx_seminars (check out only the “trunk” folder for the latest sources) |
The development process looks roughly like the process on Mozilla.org and aims at creating high-quality code and facilitating learning from other coders.
Look in the Known Problems and To-Do list sections of this documentation for things to do (or use your own ideas). Please always use the latest code and documentation from SVN for this as someone else might already have completed that task.
File a bug report in the bug tracker and write which task you intend to tackle.
Write the necessary code and test it locally. Make sure it works and doesn't generate any warnings or errors.
Create a patch and attach it to the bug report. Write that this patch is ready for review.
Contact someone from the development team to give your patch a peer review. If the reviewer wants to have something changed, change that (or persuade the reviewer why it shouldn't be changed). Repeat this step until the reviewer is content with the patch.
Contact Oliver for check-in approval.
If you have the approval, you can update and commit to SVN. In the check-in comment, write the number of the bug report, what the patch changes and who has reviewed your patch. It is also possible that the reviewer checks the code in.Example: [Bug 1840] Create an extension icon, r/a=Oliver
Close the bug report.
Notice: To commit files to the SVN, you need a SourceForge.net account to get write access (please e-mail your user name to Oliver so he can arrange things). If other members of the development team will check your patches in, you don't need an SourceForge.net account.
Please don't change the Manual in SVN (as SVN doesn't allow merging changes in binary files). Instead, send your changes to Oliver who will integrate it and upload a new version.
The reviewer should check for and comment on the following things:
Does the code conform to the TYPO3 Coding Guidelines?
Is the code free of typos and other bugs?
Is the code easy to read and understand?
Are variable, method and class names well-chosen and do they facilitate understanding the code?
Does the code architecture go in the right direction?
Is the documentation complete and helpful?
Is the coding style good and consistent? Is the code not overly complex? Are the methods short enough (not longer than one or two screens)?
Are there no trailing spaces or trailing tabs?
Is there no code duplication?
The following points are checked before a new version is released. This workflow is started as soon as all open to-do items for the upcoming version are done. Responsible for this is the chief developer (Oliver Klee).
Remove completed tasks from the “Known Problems” part of this manual.
Delete completed or obsolete to-do items from todo.txt
Delete the milestone from todo.txt
Delete “work in progress” from the changelog and enter the release date for the current milestone
Check the ExtensionManager if there are no warnings
Generate a new ext_emconf.php (updating the MD5 hashes for all files)
Upload the extension to the TER
In the TER, update the manual TOC and the status notepad
Check in the actual ext_emconf.php to the SVN (comment: new version)
Tag the current state of the files in the SVN as a new version in the format version_0_4_2. (This means to mark all files in the actual state to belong together as one version.)
Inform the persons that are known users of this extension and persons that were in contact with the development team (concerning this extension)
Spread the official announcement to the announce mailing list and to some newsgroups.
Do a party :-)
As soon as the next entry from todo.txt is done, create a new entry for the the next version in the section “Changelog” in this document.
We use (mostly) the following Tools to work on this extension:
Eclipse with PhpEclipse and Subclipse (editor and SVN client)
http://www.bugzilla.org/ (the system behind the bug tracker)
Sourceforge.net (SVN)
