Submissions » History » Version 24
Submissions on redmine.org¶
- Submissions on redmine.org
Submissions should be written in English.
Submitting a Bug¶
Before submitting a bug report here, please make sure:
- that you're using an appropriate Rails version (see RedmineInstall)
- that your database is up to date, especially if you've just migrated from a previous version or revision (see RedmineUpgrade)
- if your problem is related to svn (or any other scm), that the proper binaries are installed on your Redmine host (see RedmineRepositories)
When filling a bug report, please give the following information with the description of your problem:
- your database manager version (eg. PostgreSQL 8.2)
- your Ruby version (eg. Ruby 1.8.7)
- your Rails version (eg. Rails 2.3.11)
- your Redmine version (pick the version number in the Affected version field) and the exact revision (eg. r1142) if you're using repository code
- your scm binary version (eg. svn 1.4) if your problem is about scm integration
- your using plugins (eg. Code Review plugin)
The simplest way to get information about your environment is to run the following command from within your Redmine installation:
Also, when reporting an application error, post the error stack trace that you should find in the log file (eg.
log/production.log). The message displayed by the application (eg. ...An error occurred on the page you were trying to access...) is useless here.
If the error you're reporting occurs when running a rake task (example:
rake db:migrate), rerun the task with the
--trace option (example:
rake db:migrate --trace) and post the full output.
Submitting a Security Vulnerability¶
If you think that you've found a security vulnerability, please report it by sending an email to:
security(at)redmine.org. Known vulnerabilities that were fixed in Redmine releases are listed on the Security Advisories.
Submitting a Feature Request¶
Before submitting a feature request here, please make sure:
- fill the subject as a sum up of your description
- fill the description as detailed as you can, don't hesitate to describe precisely how this feature should behave, try to add what benefits you're excepting from it
- please DON'T fill the target version field: let the developers decide when integrate
- please DON'T assign the feature request to anybody, let the developers deal with it
Submitting a Wiki improvement¶
When you edit a wiki page to improve its content, make sure that you fill the comment field with a descriptive summary of the changes you've made to the page. This way we'll be better able to "monitor" and "maintain" the quality of the actual wiki content.
Submitting a Patch¶
- Changes should be submitted as a single patch file. Instructions for creating a patch using svn can be found here.
- You should mention the branch/revision your patch is based on and attach it