[rabbitmq-discuss] rabbitmq bugs and issue database

[Ben Hood]

Graham,

On Sat, Nov 8, 2008 at 8:52 AM, rrabarg2 <rrabarg2 at yahoo.com.sg> wrote:
> For example, a colleague informs me that MULE has 679 open issues, 39 of
> which are critical and 200 plus major. Those in progress (i.e being
> worked on) is 8.  The "core" components appear to hold in excess of 200
> of those issues. Core routing / filters alone has 45.
>
> Terracotta has some 360+ open JIRAs, 5 critical, and only 5 in progress.

I think this observation ties in with my previous conjecture "that
traditional bug databases seem to fill up
with junk that nobody cares about."

My suggestion would be to reformulate your question to the list and ask -

"Can anybody tell me about any issue that I reported to the Rabbit list that
a) was verified by the Rabbit team as a true defect and not as a nice to have;
b) has no workaround;
c) the Rabbit team has not yet bothered to try to fix it
?
"

Similarly, you could just people whether they think that Rabbit is
buggy in comparison to other systems.

And then only accept answers from people who are not on the Rabbit team :-)

> As you suggest 'critical' could mean something quite different in MULE
> to Terracotta - but it does provide an important impression none-the-less.
>
> Personally, I'd define a 'blocker' as being a high customer impact
> defect which is the result of a core use-case failure with collateral
> damage and for which there is no work-around.  'major' would be of
> medium priority to customers and would result from a use-case defect
> for which a workaround could be found, examples might include inaccurate
> calculations.  'critical' would be somewhere in between.
>
> However, for the purposes of my query, I'm interested in the number of
> genuine bugs in your database and an indication of the numbers in the
> highest severity/priority categories - however you define them.

I would take a military style approach to classifying P1 and not P1
bugs. A showstopper is anything that prevents you from using the
system for it's core purpose, anything else is just annoying. This is
very similar to what you are describing.

I am unaware of any such bugs at the moment, so IMHO, the critical
count would be zero (to give you a management figure :-)

Furthermore, I would say characterize Rabbit's development
prioritization philosophy as being "stability and predicitability"
over "performance and features". What this means practically is that
we are working on (some unreported) shortcomings that we think will
eventually rear their ugly heads, such as linear routing, disk
overflow, race conditions in shutdown, load balancing and flow
control.

HTH,

Ben