Current version: 0.1.4 | Current status: Alpha/Stable | This page is optimized for Mozilla!






Developement process

When more and more people get into the project you need to create a common sphere of understanding and awareness for all the different people you have. Everyone will have his/her own style / understanding of certain issues. To utilize the good that comes from the diversity and combined expirience of all project members is the aim of this little development process.

Why a process? See FAQ at the bottom of the page.

Announce your participation
If you are willing to join forces with us please get into contact using the jcast-hackers mailinglist: Simply describe your interests / skills and why you wan't to help developing JCast-X. Please note that you don't need to be the ueber-guru to participate, just bring a lot of joy to code Java and you are welcome :) ! JCast-X is still a project where people should be able to learn from each other, while having fun.

Announce your code change
After obtaining membership in the SourceForge project, you should use the "Change Requests Tracker" provided by SourceForge to document your change-request. This will trigger a Design / Idea / QA -review process that takes place on the jcast-hackers mailinglist.
This process will help you get on the right way and at the same time inform everyone of your plans. After your Changerequest is "closed" you can start hacking the code.

Obtain ownership or join sub-team
Once you start working on a certain component your either become the owner of that component or join into a group that is working in the same component you wanted to participate in. Here is the current ownership / component matrix:
  • Software Design: Andre [Owner]
  • Gfx Design: Kai [Owner]
  • Core: Andre [Owner]
  • Listeners: -/- [Owner], Andre [QA]
  • Sources: -/- [Owner], Andre [QA]
  • Channels: -/- [Owner], Andre [QA]
  • Net: -/- [Owner], Andre [QA]
  • Util: -/- [Owner], Andre [QA]

Bugs / Flaws you find during development
After you joined the team of developers you will have access to the sourcecode and are able to put your expirience and knowledge into the arena ;). If you find bugs or other flaws in the sourcecode it is of great importance that
This means that even if you already fixed the bug inside of the CVS you always need to write a bug-report about the issue you fixed. Please follow that easy rule, I can not tell you often enough how important it is to have all past and present problems of your software documented inside your project.

Submit your code for review
When your code reaches a stable state (or you can't think of anything to add/remove) submit your code for review here: Review-Tracker. You can do this using the attach & upload file feature in the Review Tracker. Please try to only submit code that you checked against this short checklist:
  • It comes with a unit-test. [x]
  • It compiles (inlcuding unit-test). [x]
  • ./ run.tests executes your test.
  • No error or failure occurs in the unit-test report. [x]
  • JCast-X runs without a failure or glitch in the stream for 24 Hours straight. [x]
  • You had at least one friend of yours (another set of eyeballs) proof reading it. [x]
You can submit the new code either as a .zip or .tar.gz file which has the JCast-X_CR[Change-Request-Number] directory as the root directory, followed by either:

a) A diff -u patch file against JCast-X CVS version.
b) An archive containing only your new file and the changed files of JCast-X.

This means that if I type "tar xvfz your_code.tar.gz" I expect it to create a directory like:

`-- JCast-X
    |-- doc
    |-- lib
    `-- src
From here on code-readings of your code will start and discussions will take place on the jcast-hackers mailling list. Once your code is reviewed there are 3 possible outcomes of the review process:

a) Your changes are not approved.
b) Your changes are approved, but a list of corrections needs to be completed before the commit into CVS can take place.
c) Your changes are approved as is, you can commit your changes into CVS.

Now since this is a very fragile and delicate point in the development process, everyone in the review-team needs to adhere to some rules.

  • It is always the code which is reviewed, never the style / skill of the team member.
  • A Reviewer will never disapproved a pice of code without giving a reason.
  • A Reviewer will always try to show / teach the submitting team member a better implementation, so the submitter can effectively learn form it.
  • A Reviewer will never use any form of unappropriate language.
  • In general: "Never spoil anyones fun for coding".

Change-Reports (+2nd Iteration)
A Change-Report is a protocoll that describes multiple changes to one or more components. It is a kind of Change-Protocoll more descriptive than a simple commit message. Usually after the first development iteration ( Change-Request, Request-Review, Code, Code-Review, Commit ) work continues but the first 2 steps can be skipped and the process chain is changed to continue like this: Code, Code-Review, Change-Report, Commit. Where in the first iteration all needed informations are extracted from the Change-Request, the differences implemented through the continued development are traced through Change-Reports.
Who writes the Change-Report?
Usually the submitting team member, as he knows best what changed.

Commit into CVS
After the review process is successfully executed you can commit your changes into the CVS repository. You should do this with a reference to your Change-Request-Number + Review-Item-Number.
Example of CVS commit message (CR = ChangeRequest, RI=ReviewItem):
CR #: 443357	 RI #: 577322
New and improved Playlist-Concept.
The same template applies to Change-Reports since they are also a kind of Change-Request tracked through the SourceForge Change-Tracker.

Accept bug-reports + change-request
In case you created a new component or became the owner of one for another reason. You will be put as the "default owner" of the specified component. Every Bug-Report + Change-Request is the automatically forwarded to you. (cc: to the hackers-mailinglist). The owner of the component needs to be able and willing to take the job as the main contact person regarding bugs and changes.

As it was already said before... bugs need to be reported. You may not see the reason behind this "extra" paperwork but there is no way to object you have to do it.

Rollout / Release a package
See Release Process.

  • Does every CVS commit needs to go through a "Review-Process"?
    No. Of course it would server the code quality best if this would be done for every little thing. But this can quickly get to cumbersome and counterproductive. If your changes are too small to go through the developement process you should submit a Patch or if you are a team member be descriptive in your CVS commit message. Please note that the owner of a component will always review changes on his/her component. If your quick changes are not approved by him, he can reverse your changes at any time. (Benelovent dictator)
  • Who decides wether a review is needed or not?
    Since CVS messages are CC'ed into the jcast-hackers mailinglinst you will be notified if your Changes (Patches, CVS-Commits) need more "Documentation" ;).
  • What about Bugs should I include the Bug-Id in CVS commit messages?
    Yes. Please do so by providing ID, Status and Resolution. Example:
    BUG #: 443357
    Status: Closed	Resolution: Fixed
    The concurrent problem with listeners is fixed, 
    added needed synchronisation keyword.
  • Why are you using such a complicated process no one else does!?
    Well... this project is about learning and having fun. I wan't to learn how to be a better coder, and how to create good quality software. I have learned that it is very seldom that great software is created from a team that consists of people with different levels of "code-fu" skills. The JCast-X development process tries to enable the "black belts" to teach the "white belts". I wan't white belts to participate and enjoy the project and I believe if everyone follows this development process it should be possible. Plus... documentation is never a bad thing, and Changemanagement + Code-Reviews + Unit-testing are well accepted methods to achieve good quality software.

Page version: $Revision: 1.5 $