2009-11-12

How well does your integration stack respond to your tickets

This blog title could easily be the 2nd part in a blog series. However it is not. Just wanted to a catchy title :) But it would be interesting to check upon the state in the JIRA on terms of responsiveness. However I leave that up for others or I may take a look at this sometime in the future.

What I want to tell is that this morning I did my usual habits and thus also checked upon the Apache Camel JIRA tickets.

This morning Jörn Kottmann reported that setting the timeout on the FTPClient was not possible in ticket CAMEL-2160.

I checked upon this and agreed that it should be easier to configure in Camel and thus began improving this. About 2 hours later I committed to changes and updated the wiki page as well.

The ticket was reported 2 hours before I started working on it, so in total the ticket was open for about 4 hours.

This is a good example how well we often respond to peoples tickets in the Camel community.
I am sure we have similar examples in the past as well, this is not a isolated case.

So how well does your integration stack respond to your tickets? At Camel we strive to respond and in timely manner.

I challenge you to find a ticket which has not been touched at all in the Camel JIRA tracker.

3 comments:

22222 said...

nice post....................................................................................................

darren davison said...

Claus, it's great that this happens in Camel - we've had some very good support from the dev. community with Camel issues in the past. Unfortunately, most of our stack - as with most other people I guess - also relies on ActiveMQ. I'd be interested to see a similar investigation on their JIRA where several hundred issues all marked Major or higher have been open and untouched for years in some cases :( Can you exert any influence over there by any chance??

Claus Ibsen said...

Darren

I do agree that having hundreds of JIRA tickets untouched and open for years is not a good sign. At least I would consider this as a factor when choosing my stack.

That said. I do think you cant compare Camel and AMQ as 1 to 1. AMQ is much more advanced and used in more advanced setup than Camel. Well by this I mean that people use AMQ in a network of brokers running on many different kind of OS and hardware etc. And they have complex setup and issues.

On the otherside Camel is just a framework, an API at will. So its easier to reproduce the issue and fix it in Camel.

And I do believe some of the tickets report at AMQ are "just out of the league" you can expect as free support by people who work on your tickets in their sparetime. I think AMQ should add a category to reflect this and ask people to either get paid support or try remedy their issues. You cant expect people in their sparetime to track down complex issues on a customers AIX platform etc.

However that said at Progress for example who offer paid support do have internal JIRA for customers and I must say its complex issues that our team help address customers with.

But I am sure there are tickets in AMQ JIRA which are simpler cases and which could be looked into if more people was willing to help.