Redmine

This is of interest to me as well, as my team has recently decided to use redmine as our project and issue management tool.

As a bystander, I don't expect the Redmine development to be affected much (since that kindof was the issue for the ones forking), but I honestly think we'll see more rapid development of ChilliProject. Read up on their "why fork" page.

This is very alarming for me. The whole thing looks like a clash in the redmine team, because the Chili Team states reasons for forking which they (especially eric) could be able to steer already in the redmine team in the former times. So why not just do this in the redmine project? I thought Eric wants to coin money with his redmine and ruby know how and therefore searches for companies investing in a enterprise redmine fork and extensions he can sell. Many of this goals are in dissent to a community driven project (prioritization isn't done by money, but community voting), where money and earn of team leaders isn't the drive.
The ChiliProject fork justification can't be taken honest with the background of the last months (or it must be marked of better).
What i can can notice that since the redmine project leaderships switched to Jean-Philippe, progress is made towards more community participation and faster feature integration, so the "original" redmine clearly stays favorite for us for the near future.

I would like to see shaking hands and go on together in one project -there should be enough place for both sides to implement their ideas in one project.

That is what would be best for the community in my opinion. That is the solgan for both projects, isn't it?

Terence, maybe you know something I don't. But the inability to steer Redmine towards a more community-driven project is stated as one of the big reasons for the fork, no? As far as I know, Eric has been making money from developing open source plugins for Redmine for quite some time, so I don't see the conflict there.

But, nonetheless, the different developers on the Redmine team did not feel like they had the same goals and priorities, and I don't see what the problem with forking then is. Most likely, the alternative would be to just skip doing work on Redmine and NOT fork, which would just be worse.

Hmmm...

I have participated as translator to Bulgarian for 3-4 months and already see differences in i18n usage. Redmine 1.1.1 uses

%{count}

{{count}}

While the internals of the projects could differ, there is possibility to share ideas among them for features, user interface etc. This would make both projects better.

Happiness to all.

ChiliProject's has been launched on the basis of a 1.0.4 version of Redmine, which does not include some of the latest commits related to upgrading towards rails 3 (compliance with 2.3.10 is planned for 1.2.0) and dropping deprecations like the {{<label_id>}} format for translation.

They're actually in the process of reviewing these commits to integrate some of them in their trunk.

Not sure that everything I wrote here is English, sorry for that.

1. a beautiful and very powerful design.
2. useful features with no gadgets.
3. few developers

In the past, JPL was the only one who decided what new feature had to be include in the trunk. It was possible to submit patches but JPL made a good code's review and some refactorization before integrate them. I liked this way: it produced a very stable application and I suspect that's why I never had troubles with redmine since 3 years...
Now, I made several plugins and a lot of patches to fit my needs. I have 350 users, 120 projects, and it will continue to grow. I think that, when you choose an opensource application to support a huge part of your business activity, you have to trust the developer... and that's what I did. JPL has proved his capabilities to drive redmine's development and to produce a quality product. Right now, Chiliproject not!!!
There are a lot of discussions & explanations, on their website, but I didn't see one new commited line in the trunk ;-) I'm pretty sure that Chiliproject will start soon and I hope it will be a success story but, for me, I will stay with redmine...

Sorry too for my english...

I want to try to clear up any confusion here about ChiliProject.

Terence Mill wrote:

This is very alarming for me. The whole thing looks like a clash in the redmine team, because the Chili Team states reasons for forking which they (especially eric) could be able to steer already in the redmine team in the former times. So why not just do this in the redmine project?

Even as a committer to Redmine I ran into roadblocks trying to get code into Redmine. I met resistance even for features that a large part of the Redmine community was wanting. To use an American expression: "there were too many hoops to jump though", even for me. I know it's even worse for contributors who have to continuously resubmit patches to issues while they wait for feedback.

I thought Eric wants to coin money with his redmine and ruby know how and therefore searches for companies investing in a enterprise redmine fork and extensions he can sell. Many of this goals are in dissent to a community driven project (prioritization isn't done by money, but community voting), where money and earn of team leaders isn't the drive.

No, that's not it at all. Like Stefan Hållén said, my business has been providing custom development for Redmine for a few years now. During that time I've released almost every line of code to the community and have tried to integrate it into the Redmine core as much as possible. Much of that code sits as "waiting for feedback" or had to be abandoned (see above).

Yes I will continue writing code for clients but only the code that helps the community will make it into ChiliProject. Due to some different processes than in Redmine, I'm hopeful that code will be able to be integrated at faster pace than before. Money doesn't give prioritization to my code at all (or anyone's code). I've said no to clients many times when the feature isn't useful to the rest of the community (most of this code becomes one of my plugins).

ChiliProject will, and always will, be open source and free (as in beer and speech).

What i can can notice that since the redmine project leaderships switched to Jean-Philippe, progress is made towards more community participation and faster feature integration, so the "original" redmine clearly stays favorite for us for the near future.

The Redmine project leadership has always been Jean-Philippe. I stepped up temporary to help out in 2010 because he disappeared for several months and stopped responding to emails (truthfully, myself and a lot of other developers were afraid something terrible happened to him). Thankfully he was just on an unannounced break and has been more active recently which is probably what you are seeing now.

Arnaud Martel wrote:

There are a lot of discussions & explanations, on their website, but I didn't see one new commited line in the trunk ;-) I'm pretty sure that Chiliproject will start soon and I hope it will be a success story but, for me, I will stay with redmine...

ChiliProject uses a different development model then Redmine, most activity happens in developer branches and then gets integrated into the main repository when it's ready. For example I've been doing major code reviews to the past 200 commits to Redmine and getting it ready to integrate into ChiliProject in a branch. I'm also publicly sharing these notes too, I think there are a few things I found that Redmine could benefit from my reviews too.

I hope this clears up some concerns about the ChiliProject fork. We want to make sure both communities can get along and share resources (e.g. code, committers). In no way should anyone feel that they have to "belong" to one project or the other, use the project that solves your problems the best and switch if that choice changes.

Feel free to ask me any questions you have, I'm easy to find online (published email, twitter account, and active in the forums).

Eric Davis

No hard feelimng about all you said, wish the project all the best.
Hopefully that won't split the community an half the power on both trains.

I would like to see to keep portabibilty from redmine to chili and back for a long time, so that the user don't has to bet on one horse only.

However i am still disappointed by both teams, that it isn't possible to go along together.

I clone Redmine mirror on Bitbucket and transplant Chili using hg-git and Transplant Extension.

https://bitbucket.org/marutosi/chili-transplant

These are TortoiseHg 1.1.6.1+4-afe9b5d1f997 on my Fedora 13 images.

I imported recent Chili commits to Redmine.

• https://bitbucket.org/marutosi/redmine-import-chili
• https://github.com/marutosi/redmine-import-chili

Is it possible to do like Debian and Ubuntu?

Olivier 254 wrote:

Is it possible to do like Debian and Ubuntu?

In what way do you mean?

I suppose, that the new features and the bug fixes made in Redmine to be implemented in ChiliProject and vice versa. This could be done while the projects are still close each to other.

As far as I know, that's already what's happening by looking at Toshis post and graph.

I think we can just look at this page: http://www.ohloh.net/p/compare?project_0=Redmine&project_1=Chiliproject
Although number of chiliproject's contributors grows, number of commits is decreasing.

Nevertheless, there are also some good features redmine shall integrate.

Most to say is the advance in theming possibilities, like right side menu (default supported) and grouping feature.
https://www.chiliproject.org/issues/559

If using more than 4 additional plugin with project tabs, standard redmine theme wraps ugly. Grouping things and making this configurable independent of plugins default would be best.