At the moment (May 2008) there are three 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 Klee
The inventor of this extension who is the chief developer. Oliver keeps track of the road map, the global direction of the extension and provides the most new functionality and bug fixes.
Mario Rimann
Joined the team in October 2005 and is involved in writing documentation, providing bug fixes and developing new functionality. Recently he has also coordinated the translation work with several translators.
Niels Pardon
Joined the team in December 2006 and is involved in creating and planning the new back-end module. He also provides bug fixes and helps out where help is needed.
We have a page in the TYPO3 wiki for storing texts, drafts and other stuff.
We use the mailing list/newsgroup on lists.netfielders.de for talking about development.
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, you can either download the nightly builds from http://typo3xdev.sourceforge.net/ or retrieve the files from the SourceForge.net Subversion (SVN). These are the access parameters as entered in Eclipse/Subclipse/Subversive:
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 | typo3xdev.svn.sourceforge.net |
Repository Path | /svnroot/typo3xdev/ |
Module name | tx_seminars (check out only the “trunk” folder for the latest sources) |
Note: The nightly builds and the code from SVN might still contain severe bugs, break your fridge or make your cat lose all its hair. Use them at your own risk. You have been warned.
We generate statistic reports on our work on a daily base. These reports are generated using StatSVN and are available at http://rimann.org/index.php?id=110.
The development process looks roughly like the process on Mozilla.org and aims at creating high-quality code and facilitating learning from other coders.
Make sure to always use the latest code and documentation from SVN.
Look in the bug tracker if your specific bug or feature request already has been reported. If this is not the case, enter a new bug report/feature request.
Set yourself as the bug's assignee to show you'd like to work on this bug. At this point, the bug status still is NEW.
Assign the bug yourself when you've actually started to work on this bug. This will change the bug's status to ASSIGNED.
Use a test-first approach: When you add a new function or change a function, first write some unit tests that fail as long as the bug is not fixed and that pass when the bug is fixed.
Write the necessary code and test it locally (in addition to the unit tests). Make sure it works and doesn't generate any warnings or errors.
Create a patch. Make sure to read it yourself first. Then attach it to the bug report. Check “patch”, set “review” to “?” and select “Seminar Manager QA” in the drop-down list next to the question mark.
The reviewer might give you a review- and list the things that need to be changed. In that case, go back to the previous step and create a new patch.
Or the reviewer might grant you the review, giving you a review+ (possibly listing some things that need to be changed bug that don't require a new review).
If you have the review+, you can update and commit to SVN. Never check in code that has not been reviewed yet! 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
Resolve the bug report as FIXED.
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) unless you have explicitly been allowed to do so. If you're allowed to change the manual, please make sure to SVN lock it before you start editing it.
This extension follows the following code style guidelines:
on top of that: phpDocumentor documentation
on top of that: TYPO3 Coding Guidelines
We then have added a few modifications, additions and clarifications:
Use UTF-8 and Unix line endings.
Remove all trailing spaces and trailing tabs.
Don't use end-line comments.
Lines must not be longer than 80 characters. This also includes comments and documentation comments (also for @param and @return). The only exception are include_once statements (which should be on one line, overriding the 80-character rule) and the declarations of unit tests. Concerning line wrapping, have a look at the line-wrapping guidelines.
Use early returns only for guard clauses and only if they greatly improve readability.
Don't use @var.
Functions that return void don't need to have a return statement.
File names are allowed to be longer than 31 characters.
Use strict camelCase for function and variable names. Good: createIndex, readIsoImage. Bad: create_index, readISOImage.
Private and protected function and variable names must not begin with an underscore.
Don’t add blank lines after { or before }.
Don’t check in commented-out code to SVN. If you absolutely need to do so anyway, you must include a comment (including a reference to a bug) stating when this code can be removed or reactivated.
Sentences in comments (including @param and @return) should either be
incomplete sentences that start lowercase and don’t have a full stop at the end, or
complete sentences that have a capital letter at the start and a full stop at the end.
Comments should be written in the third person (or in the first person in some cases).
We already require PHP5 and don't need to be PHP4-compliant anymore. So please use type hinting, exceptions and access modifiers like public or private and don't use @access anymore. Also use public/private/protected instead of var for member variables.
Generally, regressions should be avoided by using unit tests. As some parts of the code are not covered by unit tests (or some cases are not covered yet), regressions might be undetected by the existing unit tests. Those regressions then need to be fixed and covered by unit tests. We have agreed on the following strategy for this:
If there have not been any checkins after the checkin that has caused the regressions, we will directly revert the checkin. We then need a fixed version of the patch (including unit tests for the regression). Otherwise:
If a developer can fix the problem within 48 hours (including unit tests for the regression), we will do that. Otherwise:
If we can reverse-apply the patch that has caused the problem within 48 hours, we will do that. We then need a fixed patch. Otherwise:
If all else fails, we will just do our best to fix the problem as fast as possible.
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.
Enter the release date for the current milestone in the changelog.
Check the Extension Manager if there are no warnings.
Generate a new ext_emconf.php (updating the MD5 hashes for all files).
Upload the extension to the TER.
Check in the actual ext_emconf.php to the SVN (comment: new version).
Create an SVN tag.
If this is a major release:
Create an SVN branch.
Enter the next milestone in the bug tracker.
Change the version number in ext_emconf.php to x.y.99 and check in the changes to the trunk (not the branch!).
Move maintenance bugs to the next maintenance version.
remove the old upgrade notes in the trunk manual and new notes for the next version
Enter the new (upcoming) version into changelog.txt.
Enter the just-released version in the bug tracker.
Important: Wait until the new version appears in the TER (this may take some time).
Update the extension on the translation server (Mario)
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 newsgroup.
Do a party :-)
We use (mostly) the following tools to work on this extension:
Eclipse with PhpEclipse, Aptana and Subclipse (editor and SVN client)
The GIMP (image manipulation software)
BugZilla (the system behind the bug tracker)
Sourceforge.net (SVN)
StatSVN (for statistics on the SVN repository)
