|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
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:
- 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]
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:
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".