Frequently asked questions¶

Why shall I use ChiliProject and not Redmine?¶

ChiliProject is a fork of the Redmine project. One of the main reasons for forking was to gain stronger growth and speed in development by opening the process of contribution to a larger community. We believe that this will gain trust in the community and in the product. That is why we think that you can trust in this project, too.

Is ChiliProject OpenSource?¶

Yes, it is provided under the GNU General Public License, version 2.

When will Rails 3 be supported?¶

Rails 3 rewrote how Rails Engines work and are not fully backwards compatible. Since Engines are used by ChiliProject for our plugins, we cannot upgrade to Rails 3 until:

• A major ChiliProject release, due to breaking backwards compatibility
• Rails 3 Engines are completed. Rumors say that will be with Rails 3.1
• A migration and upgrade path for existing ChiliProject plugins is released

For more details, see #601.

What is Bluemine?¶

Bluemine was the code name for ChiliProject before we had an actual name. It is based on the Ruby's community fascination with colors (RedCloth, BlueCloth).

What is the proper name for ChiliProject?¶

The proper name is ChiliProject, as CamelCase. chiliproject is okay too when it's referring to "code" things like a filesystem path (e.g. install to /var/chiliproject) or package (e.g. apt-get install chiliproject).

Chili Project, chili-project, and chiliProject are not the correct spelling.

How come I have to visit the repository module before I see any changes?¶

ChiliProject needs to load the repository data into the database before it can be used. This happens when visiting the Repository module by default but you can also schedule a cronjob to load the data on a regular schedule.

rake redmine:fetch_changesets RAILS_ENV=production

On Git, Mercurial, and other repositories that have a local copy need to have the changes sent to the repository first. e.g. git push for git.