I'll answer what I can, the other guys can fill in the holes:

Is it possible to use a redmine database under the ChiliProject (or is there at least a migration tool)? If so, does the ChiliProject intend to keep backwards database compatibility to redmine?

The first release of CP will be fully compatible with redmine (1.0.5 I believe) and will include a migration task and tool to get users onto CP from redmine.

Will a demo be set up?

Yes, we'll have this up soon, you can watch #58 for updates

I noticed some style changes (looks like just CSS changes), but very little. To fork a project like this, it should probably change the layout a little bit so people don't get confused as it still being redmine. Are there any plans to change the layout?

Long-term there are definetly plans for lots of UI fixes, couldn't tell you about anything short term.

Does the blog replace the news module?

The news will have mostly just the release announcements, and the blog will have more community type stuff. See #36 and #37

how does number of Chili project developers compare to Redmine ones?

Alexey Java wrote:

how does number of Chili project developers compare to Redmine ones?

I would say roundabout equal. But I think this doesn't really matter at such an early project stage. What's more important is, that we are eager and motivated to get this thing rolling. We have planned a rather fast development cycle and are willing and capable to quickly generate actual results.

Eric Thomas wrote:

• Does the ChiliProject intend to keep pulling in revisions from the redmine repository?

Yes, we intend to work with Redmine, not against it. Thus, we are probably swapping features where appropriate.

Eric Thomas wrote:

• Does the ChiliProject intend to keep pulling in revisions from the redmine repository?

Yes, we haven't decided on how often but I'd like to pull features and bug fixes from Redmine into ChiliProject. (And the other way too, ChiliProject is open so Redmine can pull features from us too).

• I noticed some style changes (looks like just CSS changes), but very little. To fork a project like this, it should probably change the layout a little bit so people don't get confused as it still being redmine. Are there any plans to change the layout?

The basic style changes you see here is just from a theme. We are planning to do a larger redesign soon, we just wanted to launch early.

• Does the blog replace the news module?

It will for us. The News module doesn't really compare to a full blogging engine like http://blog.chiliproject.org (Wordpress) so we decided to disable News for now. The actual ChiliProject code will still include the News module, which is great for internal or smaller projects.

Eric Davis

I agree that redmine suffers of the lack of commiters (2 or 3 actually, JPL, Toshi for SCM & JBBarth) which really slow down its development process, but actually you are just going to split the community in 2 and have work done twice, because I suspect core redmine will rarely pull your changes, as there is already a lot of patches waiting in its trackers.

You should have a common project with JPL, why not make the debate public ?

Hi Etienne, nice to see you here, even if it's only to discuss things.

Etienne Massip wrote:

You should have a common project with JPL,

We've tried. I was tempted to say that it failed, but that would be wrong because it's never really begun in the first place. Let's say it didn't work out.

why not make the debate public ?

We might make it public in the future, but we wanted to launch on technical and community-related considerations, not interpersonal ones.

I for one embrace the change. Sometimes, different people want different things, and seeing the commitment you guys put into, and tried to put into Redmine and knowing you can actually put all your efforts into ChilliProject is really promising. In my opinion :)

I generally hate forks. This is because in 99% of those cases the fork is the result of people being unable to put their Ego aside. I was sad reading that the Redmine developers split efforts.

To be honest I haven't understood how this project is going to be different from Redmine and I currently see no valid reason to switch over to CP.

BTW, I am just an enthusiast. I use Redmine to manage my personal open source projects. I am here because of curiosity, trying to understand why this fork has happened.

Well, the difference is that the developers will be able to actually put their efforts into the project, and get RESULTS from their efforts, no?

Also, hopefully, it will be easier for other developers to help out.

But couldn't these things happen within the Redmine project scope? Redmine is a well-established open source project. Problems should have been announced publicly, so that the developers and their views on the development process could be judged and criticized by the community. If such discussions failed, then there would be more valid reason for a fork.

I wasn't part of those discussions, since they were behind closed doors. As of right now, the ChilliProject team have not shared the issues to the public which I think is out of respect for the rest of the Redmine team. The issue, as far as I've understood, is that the ChilliProject devs put lots and lots of efforts into making Redmine more of a community product and getting more momentum in the development, but was held back due by others in the Redmine team.

The ones on the ChilliProject were the ones really pushing Redmine forward in my eyes, so I don't see how the fork could be a bad thing if Redmine management didn't want to have a more transparent and rapid, community-based development.

But I'm just a bystander :) To me, almost all the important former Redmine devs are now on ChilliProject so I think this will be a positive fork :)

I am a redmine user that took the easy way of installing redmine through turnkey-linux appliance. I am still on the 0.8.4 release of redmine. I found it to cumbersome to learn ruby and take the risk of breaking my install by upgrading. Now I find a new active fork. It is a pity this could not get achieved inside the redmine project, but as a lot of redmine developers are in, this fork has potential. Still, there are a lot of open questions.

• There is some clear information missing of what is different in between redmine and chiliproject. It would be wise to have some articles with a list of differences, even if irrelevant. As an outsider, you do not read the development tracks. (sorry, guys)
• It would also be nice to have different articles explaining upgrades from the different redmine versions.
• I liked the redmine professional looks. Could the chiliproject bear a redmine theme. No need to have it enabled by default, but it would still be nice to have it as an option.
• Are there any plans - to assist with building - a turnkey or other appliance with it?

As a side-note, I lack a better bugtracking tool. I use mantis because the redmine tracking tool (in version 0.8.4) is not up to level. Is there a plan to integrate e.g. mantis or be on feature-par with mantis?

George Notaras wrote:

But couldn't these things happen within the Redmine project scope? Redmine is a well-established open source project. Problems should have been announced publicly, so that the developers and their views on the development process could be judged and criticized by the community. If such discussions failed, then there would be more valid reason for a fork.

Totally agree : if they would have make it really transparent (btw, I think redmine development is transparent, if not well organized nor rapid), ChiliProject creators should just have start by publicly debate of their willing to fork on redmine forum.

Now, it's too late and too bad.

Nevermind, wish redmine & chiliproject won't just step on each other's toes too much (approximative translation from french, humm) =)

I forked TortoiseHg and I am maintaining.
https://bitbucket.org/marutosi/tortoisehg

Some python codes were merged to upstream.
https://bitbucket.org/tortoisehg/stable/changeset/504535c7d112

But, C++ code is pending to merge.

• https://bitbucket.org/marutosi/tortoisehg/wiki/Home#!story
• http://groups.google.com/group/thg-dev/browse_thread/thread/dd3339f9b2665ee9
  • http://groups.google.com/group/thg-dev/msg/73afd1fb7799cd93

TortoiseHg 2.0 is planned to release at March 1st.
And new "stable" named branch was created at 2011-02-02.
https://bitbucket.org/tortoisehg/stable/changeset/c997ed09ef96

I will create a new patch for "default"(=devel) named branch.

Yuya Nishihara who contributes Redmine Mercurial patches is TortoiseHg committer.

are you guys going to import existing feature&bug requests and code patches from Redmine.org database?

Alexey Java wrote:

are you guys going to import existing feature&bug requests and code patches from Redmine.org database?

The database is not something we have access to, but I'm sure the more popular requests will make their way here. As developers coming from the community directly we are keenly aware of the many requests that are long-standing that have been unable to be incorporated into redmine due to a multitude of reasons, several of which this project corrects.

Yves De Billoëz wrote:

• There is some clear information missing of what is different in between redmine and chiliproject. It would be wise to have some articles with a list of differences, even if irrelevant. As an outsider, you do not read the development tracks. (sorry, guys)

There will be but right now ChiliProject is pretty much the same code as Redmine. As our development gets started we will start to document the differences.

• It would also be nice to have different articles explaining upgrades from the different redmine versions.

I totally agree, it will be addressed with our first release. #32

• I liked the redmine professional looks. Could the chiliproject bear a redmine theme. No need to have it enabled by default, but it would still be nice to have it as an option.

ChiliProject will support themes just like Redmine. The site here (chiliproject.org) is running a custom theme to prevent confusion between this site and redmine.org.

• Are there any plans - to assist with building - a turnkey or other appliance with it?

I would love to see that happen. I also want to work with other projects to get ChiliProject packaged up (e.g. Debian, Ubuntu).

As a side-note, I lack a better bugtracking tool. I use mantis because the redmine tracking tool (in version 0.8.4) is not up to level. Is there a plan to integrate e.g. mantis or be on feature-par with mantis?

I haven't used Mantis for years now and 0.8.4 is really old. Could you start a new forum thread with a list of what features you think is lacking?

Eric Davis

Alexey Java wrote:

are you guys going to import existing feature&bug requests and code patches from Redmine.org database?

We don't have access to the database so we can't do an import. We have setup a "Remote issue URL" field to track requests on other sites, like redmine.org or the Debian Bug Tracking system. #141 has an example of how we are using this.

Eric Davis

my bad, I should have been more clear. when I said "redmine.org database", I actually meant redmine.org website