There are the following roles that can help improving FreeProfiler:
Below is a typical cycle to contribute to FreeProfiler:
1.The contributor first log features or log bugs. Before logging any feature request or bug, it is a good habit to check if there exists same feature/bug.
Here is the feature list of FreeProfiler.
Here is the bug list of FreeProfiler.
When the contributor determines to fix a bug or write a feature, he/she needs to post a comment to that feature page to let everyone knows that he/she is working on that feature.
2.The contributor downloads latest source code from FreeProfiler cvs repository.
CVS anonymous access: pserver:firstname.lastname@example.org:/cvsroot/freeprofiler
3.Coding; write documents under Document/Help/ and add necessary links.
4.Compress the changed files into a zip file and upload the zip file to the associated feature/bug page.
5.Discuss with other contributors. If necessary, the author may need to make some changes to their code.
6. Finally, a developer will submit the code changes for the contributor.
When a contributor submitted many high quality patches, he/she can send a mail to renqilin at gmail.com. The mail should include his/her unix user name in sourceforge, what he/she did in FreeProfiler. If the request passed, he/she will have direct write permission to FreeProfiler CVS repository.
FreeProfiler is developed under Microsoft Windows. Theoretically, the following platforms are supported:
Windows 9x/Windows NT/Windows 200x/Windows XP/Windows Vista
You need the following tools to develop FreeProfiler:
1.When project starts, there is no goal, no plan. Nobody will ask developers to coding. Every contributors can log features or log bugs.
2.Then, each contributor can choose a feature or bug that he or she wants to fix. Contributors should post a comment under that feature so that others know that the feature is currently working in progress. By doing so we could avoid duplicate works.
3.Each contributor is coding locally. When coding finished, the contributor needs to generate a patch (Include code changes, change list description, documents, and test) and upload the patch file to the feature page.
4.Everyone can then view the patch file and discuss it. If the author believes that something needs to be changed, then go to step 3, otherwise, the author can ask the admin to submit the patch into cvs server.
5. A developer submits the patch and resolves conflictions.
6. When project maintainer believes there are enough new features and it is time to publish a new release, he or she will create a new code branch (we call this release branch), suspend any new feature patches to the release branch, and publish the beta version of the release branch. For main branch, everyone is still doing the same job from step 1 to step 5.
7. Based on feedbacks from beta users, everyone can log bugs against the release branch. Anyone can choose a bug to fix. The bug fix cycle is similar to step 2 to step 5, but maintainer will submit the bug fix patch in both the release branch and the main branch.
8. Based on the bug count of any a branch, Admin may make his or her judgment to tag that branch and publish a new build.
Any suggestions please log feature request or bug report. To contact admin, please send a mail to renqilin at gmail.com
Last updated by Qilin.Ren, Jan 20th, 2009