General Development
Table of Contents
MantisBT, an open source project, allows you to contribute changes you make back to the core package. This allows others to benefit from your work and can help you from having to reimplement your changes after an upgrade. This page should provide useful information on procedures to ensure development goes smoothly.
Install and Set Up Apache + PHP + MySQL
Some sites that will guide you through a step-by-step installation and setup process.
- Bad Blue - simple webserver with PHP support for Windows
- Apache+PHP - installation instructions
- PHPTriad - Apache, MySQL, PHP, PHPLIB, phpMyAdmin all in one! A bit outdated but still useful
Install phpMyAdmin
All you really need to do is edit the config.php file to be able to access your MySQL installation. Note that you will need to place phpMyAdmin in your web server directory so you can access it with your web browser. In order to secure this you should read the documentation and use a .htaccess file. If no one will be accessing your server it's not a big deal; just use common sense.
It may complain about magic_quotes_gpc. You can make sure this is on by looking in your php.ini file. Don't forget to restart apache for the settings to take effect. If that doesn't fix the warning just ignore it. I haven't had any problems.
Help and Reference sites
Please follow the
MantisBT Coding Conventions document. Code not following the convetions
will not be accepted!
Discussion and communication should occur in the
mailing lists. Please try to keep discussions public. As an open source project much of the value and excitement comes from having an process that is open to the public.
Patches should be appliable using the unix "patch" command. Make sure your .patch or .diff files will be compatible or send explicit instructions on how to apply your changes. Always specify what release you are patching against. We prefer unified diffs. Please send all patches to the mantisbt-dev mailing list.
You'll want, of course, to use an editor you like. I myself do my development in Windows and use UltraEdit. You're free to use what you like and here are some features that you'll probably want.
- Column and row numbering.
- Goto Line Number
- Word wrap toggle.
- Multiple files.
- Searching across multiple files and recursively down directories.
- Search and replace across multiple files.
- Specify TAB spaces (I use 4).
- Syntax highlighting
- Trim trailing whitespace
- DOS 2 UNIX CR/LF conversions. Your editor must be able to save files with Unix-style line breaks. This means the \n character instead of the \r (Mac style) or \r\n (Windows style). You can confirm this by viewing the file in a hex editor.
Coding Style
Please follow the
MantisBT Coding Conventions.
GIT Commits
Please keep commits short and focused. Ideally you would check in all the files affects by your change(s) at one time. You should try to commit after every bugfix or feature addition. Make sure your commit note tells enough so that another developer (familiar with the project) can make sense of what changes were made. Information might include files, functions and variables that were modified.
e.g. git commit -a -m "Modified view_all_bug page so that column alignment is better across browsers" view_all_bug_page.php
Occasionally you can make do with a trivial message like "updates for release" or "tweaked formatting." This might be when you update the Changelog, or reformatted and cleaned up code, etc.
Communication
Please use the
mantisbt-dev mailing list. This way there is a public record of development. If you have a matter you would like to discuss in private them emailing directly is fine.
Testing
In general I would prefer that you test using at least two browsers. This way most browser dependencies can be caught. I recommend testing with Internet Explorer for Windows and one of Firefox, Mozilla or Netscape. This captures the vast majority of actual users. Others that might be considered are Opera, Konqueror, Safari and OmniWeb.
Other rules
Make sure you sign up on the bugtracker and received developer access.
You can mark a bug as resolved if it is commited in GIT. Please don't close bugs until that release is publicly available.
