• Users should read that fuc*ing installation guide
• Users should read that fuc*ing FAQ
• Users should search that fuc*ing forums
• Users should be polite AND patient on that damn IRC chan

:)

Martin, eeeeh... I have feeling you are marketing guy, heh? ;)

No. I hate marketing. But I'm deep in the meaning of open source and I think we should define common goals instead of talking about technical details. The whole opensource thing and redmine as an open source project is about defining goals, splitting tasks and having a common idea of what should be done.

At the moment there's just one guru integrating patches. Don't get me wrong. I love redmine and the people around but this project needs clear goals and a core team that consists of more than one member :)

Cheers!

Here's my rant, I'll try to stay on topic as much as possible.

4. QUALITY - It has to be stable and tested.

Code LOC: 13071     Test LOC: 5375     Code to Test Ratio: 1:0.4

The test coverage saddens me. Ruby on Rails provides a great foundation for testing but Redmine isn't taking advantage of it as much as it can. Really every one of the 88 open defects should include a test along with the fix. I'll be the first to admit that I'm no better, I've submitted a few patches without test coverage. But we can improve this.

5. EXPANDABILITY - It needs a real plugin system that users can build independant plugins without modifying the core

My thoughts about this are public. See #1677, #1143, #783 for what I'm trying to do to fix this.

6. CONNECTIVITY - It needs a solid webservice interface and restful controllers for better integration

Like item 4, Ruby on Rails makes this super simple. Realistically, there isn't much needed but no one has stepped up to implement it yet. I'd implement it if I wasn't so busy on my customer's projects.

7. DOCUMENTATION - It has to be well documented for both: users and developers

The user documentation is getting better but the developer (both core and plugin) is painfully lacking. I know a ton about the plugin API but that's from hacking on the core for over a year. Once again, I'd start writing some if I wasn't so busy on my customer's projects.

Sidenote: If anyone is working on a plugin and needs help, please email me and I'll do my best to lend you a hand. I've created 8 plugins already so I have a little bit of experience ;)

Martin Herr wrote:

At the moment there's just one guru integrating patches. Don't get me wrong. I love redmine and the people around but this project needs clear goals and a core team that consists of more than one member :)

This is my biggest problem with Redmine. Having one person as the gatekeeper for the development is really limiting constraint(1). That's why I setup automatic pushes to GitHub and am actively encouraging people to fork the code on there. Allowing more people to modify the code in the public will help it grow and will make it so much easier for the core "team" to integrate patches.

Not wanting to just rant about what's wrong, here is what I think we can do to improve the project:

• Don't accept patches without documentation and tests
• Make a plan to add REST or some kind of web API
• Make an effort to document how plugins are created and used in order to make it easier for people to start building them
• Expand the core team, either more people with more commit rights or a distributed organization

Eric

¹ Yes I know there are several people with commit access but from what I've seen 99% of commits are by JPL and the others are commiting to branches. http://www.redmine.org/repositories/stats/redmine

I am working on packaging Redmine up for Debian. That should help with 3. Community and to some extent 8. Communication. Don't get too excited though, this is my first time building a Debian package and its probably going to take a little time. :)

On a side note, I am going to be distributing Redmine as part of the first product offering from my company. This means that as soon as we are able we'll be giving back to the community in more real terms. Probably money, but it could also be better documentation or some other non-tangible offering. I firmly believe that FOSS only works when everyone gives back to the community and I intend to do all I can to help Redmine succeed!

Later...
Richard

BTW: We were looking at Bugzilla but Redmine really blows the doors off of it in almost every way. I've been very impressed. Keep up the great work!

Hi Richard,

I'm a big Debian fan (my wife too ;) ) with 2 servers and 2 desktops and 2 laptop with this cool distribution, but since Ruby world is moving so fast, I'm not a user of ruby-related deb' package: the only I'm using are ruby, irb and rdoc. I have setup rubygem from sources and every single other ruby things are up with gem. Redmine itself, as you can see, grow very fastly, even with 1 commiter. It's rare that people want to wait for the hyped new feature of a soft under heavy development: does redmine deb' package would be very used? Maybe for some production sites, but... I doubt it's the right time to package it. Maybe you should wait for the 0.8 for this.

Just to be clear: I don't want to discourage you to package redmine for debian, but from my point of view (which could be totally wrong), this is too early.

Regards,

Thomas.

I feel the same as Thomas, most Ruby and Rails development is too fast paced to keep packaging up to date. What about if there was a package that wrapped all the bits Redmine needs to run (e.g. MySQL, Ruby...) and providing a script to download a release from the web. I see a prompt:

Download which version of Redmine to /var/redmine ?

1. 0.7.0
2. 0.7.0-RC1
3. 0.7.1
4. 0.7.2
5. 0.7.3
6. trunk
o. Other version before 0.7.0

redmine > _

(numbers taken from the svn tags folder)

That way, the package can stay current as long as any external dependencies are taken care of (e.g. Rails 2.1.0).

Eric

It's rare that people want to wait for the hyped new feature of a soft under heavy development: does redmine deb' package would be very used? Maybe for some production sites, but... I doubt it's the right time to package it. Maybe you should wait for the 0.8 for this.

Thomas, I definitely agree with your thought process here and as slow as I am it will probably be 0.8 before I get it packaged up anyway. :) In fact, I am doing this for my own production site and I thought it would be nice to give back to everyone. Besides, just because I package it up doesn't mean that people can't go out and install it raw.

I feel the same as Thomas, most Ruby and Rails development is too fast paced to keep packaging up to date. What about if there was a package that wrapped all the bits Redmine needs to run (e.g. MySQL, Ruby...) and providing a script to download a release from the web.

Eric, I'm fairly certain that this type of package would not get accepted into the Debian system. Building generic packages that just download other pieces of software is frowned upon. Basically your just throwing away all the power of the Debian system (package dependencies, purge, re-install, automatic updates, etc.) while gaining no benefit from just installing it yourself. Another problem is that packages should only include things that are directly related to a particular piece of software. Bundling multiple "things" like MySQL & Ruby into a package is strictly forbidden because it causes huge packages that tax all of the systems and it makes it almost impossible to upgrade. What happens when you have 3 versions of MySQL installed on your machine? "Bad Things", that's what.

Now that's not to say that all is lost, the Debian folks have a solution for fast moving packages; multiple repositories.

• 'stable' is where all the production packages go and its a very slow moving target - it takes months to get things into it.
• 'testing' is a bit more lax, the packages still have to be solid but it only takes a couple of weeks to move into.
• 'unstable' is just that, unstable, and is pretty easy to update. In fact you can update several times a day if you wish.
• 'security' is where all the security related updates go.
• 'backports' is a place for fast moving but stable packages to reside. If your software is evolving much more quickly than 'stable' allows, this is the new versions live.
• 'experimental' is a no-holds-barred jungle. Anything and everything can go here. BEWARE! :)

In general, I envision a future version of Redmine (v0.8 ??) in the 'stable' repository with frequent updates to 'backports'. This is really the best of both worlds; the production users in the world get a rock solid version and everyone else can get the fancy new features earlier than normal.

Richard Hurt wrote:

Eric, I'm fairly certain that this type of package would not get accepted into the Debian system. Building generic packages that just download other pieces of software is frowned upon.

I did not know that. I've seen some packages do that so I thought it was acceptable.

Bundling multiple "things" like MySQL & Ruby into a package is strictly forbidden because it causes huge packages that tax all of the systems and it makes it almost impossible to upgrade. What happens when you have 3 versions of MySQL installed on your machine? "Bad Things", that's what.

I meant to say, have the Redmine package have dependencies for all the other packages it needs. So if you have MySQL 5 already installed, it wouldn't install another copy. Same for Ruby, the Ruby bindings, etc.

Eric