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: jcast-hackers@lists.sourceforge.net. 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 YOUR SUBMIT ALL BUGS INTO THE BUG-TRACKER, INCLUDING THE ONES YOU JUST FIXED. 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] ./build.sh 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_CR443357/ `-- 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.

FAQ

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.