You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@qpid.apache.org by Aidan Skinner <ai...@apache.org> on 2008/07/07 11:45:22 UTC

Jira decrufting bug day hugathon party

Hi guys,

with M3 rapidly descending upon us, it seems prudent to have an
all-day party on #qpid on partychat to dung it out a bit and resolve
old things. How does 1000 EDT / 1500 BST / 1400 UTC suit people?

Be there or get prodded about stuff via IM directly. ;)

- Aidan

-- 
Apache Qpid - World Domination through Advanced Message Queueing
http://cwiki.apache.org/qpid

Re: Jira decrufting bug day hugathon party

Posted by Aidan Skinner <ai...@apache.org>.
On Tue, Jul 8, 2008 at 12:01 PM, Aidan Skinner <ai...@apache.org> wrote:

> On Mon, Jul 7, 2008 at 10:45 AM, Aidan Skinner <ai...@apache.org> wrote:
>
>> with M3 rapidly descending upon us, it seems prudent to have an
>> all-day party on #qpid on partychat to dung it out a bit and resolve
>> old things. How does 1000 EDT / 1500 BST / 1400 UTC suit people?
>
> Silence is aquiescene, bug triage super cleanup happy funtime will
> begin in 3 hours!

I've been having problems with partychat0-3 so am using
partychat4@gmail.com this afternoon

- Aidan
-- 
Apache Qpid - World Domination through Advanced Message Queueing
http://cwiki.apache.org/qpid

Re: Jira decrufting bug day hugathon party

Posted by Aidan Skinner <ai...@apache.org>.
Well, I thought that was quite productive, we collectively managed to
close 20 Jiras out of the 273 on the list and processed 93!

Still a few more to go though, so let's do this again on Thursday,
same bat-time, some bat-channel.

Log of the discussion from partychat for the interested:



 [3:09 pm] aidan.x.skinner  ok, QPID-24, still a problem, yes?


 [3:09 pm] aidan.x.skinner  Rob: how about QPID-42?


 [3:09 pm] partychat0  [rajith77@gmail.com] Rob, Aidan I thought
Arnaud did some work for the dtx stuff

 [3:09 pm] partychat0  [rajith77@gmail.com] not sure how complete it is

 [3:09 pm] partychat0  [cctrieloff@gmail.com] will do in a bit

 [3:10 pm] aidan.x.skinner  Rajith: I don't think it's complete, so it
should still be open


 [3:10 pm] partychat0  ["rob"] 42 I'd have to check...

 [3:10 pm] partychat0  ["rob"] let me bring up an IDE with the code in

 [3:11 pm] partychat0  ["rob"] 24 is still an issue for the java Broker

 [3:11 pm] aidan.x.skinner  Thanks. Please update it either way, since
it sounds like you have some more information than what's in the bug


 [3:11 pm] partychat0  [rajith77@gmail.com] agreed it should be open -
can we make an action item for arnaud to comment on the JIRA to let us
know what is done and what needs to be done

 [3:11 pm] partychat0  ["rob"] aidan: i can read the code if that's
what you mean

 [3:11 pm] aidan.x.skinner  rajith: if you want to mail him, feel
free. I'm only lookign for jira status changes just now though.


 [3:11 pm] aidan.x.skinner  rob: I do.


 [3:12 pm] aidan.x.skinner  carl: qpid-106, does the c++ broker do SSL now?


 [3:12 pm] partychat0  [cctrieloff@gmail.com] no

 [3:13 pm] partychat0  [cctrieloff@gmail.com] there is a guy in the
community that has done most of it

 [3:13 pm] partychat0  [cctrieloff@gmail.com] but the patch is not complete yet

 [3:13 pm] aidan.x.skinner  ok. qpid-107 needs split.


 [3:14 pm] partychat0  ["rob"] 42 is still an issue on the Java Broker

 [3:14 pm] aidan.x.skinner  oh? might be useful to update with that information.


 [3:14 pm] aidan.x.skinner  martin: can you split qpid 107 into a java
broker and a c++ (sorry, you did the java work so you get the fun ;>)


 [3:14 pm] partychat0  ["martin"] ack

 [3:14 pm] partychat0  [rajith77@gmail.com] Rob are u taking over
QPID-24? or are we gonna assign it to arnaud for an update?

 [3:15 pm] aidan.x.skinner  I'm pretty sure QPD-142 (transactions not
atomic in the face of failover) is fixed


 [3:15 pm] aidan.x.skinner  at least for the java client


 [3:16 pm] partychat0  ["martin"] only the 08/09 client?

 [3:16 pm] aidan.x.skinner  does it not throw in 0-10?


 [3:16 pm] aidan.x.skinner  rhs?


 [3:17 pm] partychat0  ["rob"] I'm not doing anything on 24

 [3:17 pm] partychat0  [rajith77@gmail.com] rob - ok cool - aidan can
we assign that to arnaud - I assume u are updating as we go

 [3:17 pm] partychat0  [rajith77@gmail.com] aidan let me ping rafi

 [3:17 pm] partychat0  ["rob"] i would suggest we don't assign
anything to anybody yet

 [3:18 pm] partychat0  ["rob"] we should work out priorities first

 [3:18 pm] partychat0  ["martin"] +1 to not assigning

 [3:18 pm] partychat0  ["rob"] people can be free to take them if they want

 [3:18 pm] partychat0  [rajith77@gmail.com] rob agreed

 [3:18 pm] partychat0  ["rob"] I'm sure we'll hit 24 when we do 0-10 support

 [3:18 pm] aidan.x.skinner  ok, 142 could still be a problem i think
so moving on


 [3:18 pm] partychat0  [rajith77@gmail.com] yep

 [3:19 pm] aidan.x.skinner  anybody know anything about QPID-144?


 [3:20 pm] partychat0  ["rob"] tumbleweeds

 [3:20 pm] partychat0  ["martin"] sorry slow loading

 [3:21 pm] partychat0  ["martin"] Think this is still an issue .. will
take note of ID as I think a newer jira superseds this

 [3:21 pm] aidan.x.skinner  thanks


 [3:21 pm] aidan.x.skinner  QPID-218, the python client now speaks 0-9
doesn't it?


 [3:22 pm] partychat0  [rajith77@gmail.com] aidan Rafi is the best to
answer that question

 [3:22 pm] partychat0  [rajith77@gmail.com] but I think it does

 [3:22 pm] aidan.x.skinner  yes, good, next.


 [3:23 pm] aidan.x.skinner  anybody know anything about ruby?


 [3:23 pm] aidan.x.skinner  for QPID-219, also 0-9 support


 [3:24 pm] partychat0  ["rob"] For 0-9 I would say if things don't
support it now; they never will

 [3:25 pm] partychat0  ["rhs"] aidan: I'd guess the answer is mostly yes.

 [3:25 pm] partychat0  ["rhs"] aidan: but it's a guess

 [3:25 pm] aidan.x.skinner  well, i looked in teh code and the test is
only for 0-8


 [3:26 pm] aidan.x.skinner  close as WONTFIX?


 [3:27 pm] partychat0  ["martin"] I'd leave it.. it may be an easy
route for a new ruby developer

 [3:27 pm] aidan.x.skinner  Martin: QPID-272 is... open? dead?


 [3:27 pm] partychat0  ["martin"] before taking on the 0-10 changes

 [3:28 pm] partychat0  ["martin"] We need to test it but I fear it may
still be an issue.

 [3:28 pm] partychat0  ["martin"] Should like to other client
exception handling QPid-940>?

 [3:28 pm] aidan.x.skinner  yeah


 [3:29 pm] aidan.x.skinner  right, QPID-287, rhs?


 [3:30 pm] aidan.x.skinner  it talks about the 0-9 branch so I'm
presuming it's irrelevant


 [3:30 pm] partychat0  ["rhs"] I think that's a safe guess.

 [3:30 pm] partychat0  ["martin"] .. it is also talking about a code
generator.. but doesn't say which one

 [3:30 pm] partychat0  [rajith77@gmail.com] aidan its irrelevamt

 [3:31 pm] partychat0  ["martin"] s/aidan/aidan:/

 [3:31 pm] aidan.x.skinner  next up is qpid-329


 [3:31 pm] partychat0  ["martin"] Feature Request

 [3:31 pm] aidan.x.skinner  I don't understand it


 [3:31 pm] partychat0  ["martin"] Do we just keep it?

 [3:31 pm] aidan.x.skinner  i think so


 [3:31 pm] partychat0  ["rob"] I think that one requires AMQP level changes

 [3:31 pm] aidan.x.skinner  qpid-363 then


 [3:32 pm] aidan.x.skinner  has anybody looked at/applied that patch?


 [3:32 pm] partychat0  ["martin"] No, but the question is still open.

 [3:32 pm] partychat0  ["martin"] Should we throw an exception or is
returning null valid?

 [3:32 pm] aidan.x.skinner  yeah, having read it a bit more carefully
i feel ambilavent about that


 [3:32 pm] aidan.x.skinner  next


 [3:33 pm] aidan.x.skinner  QPID-370, spec violation?


 [3:33 pm] partychat0  ["martin"] as with 371

 [3:33 pm] partychat0  ["rob"] don't fix

 [3:33 pm] partychat0  ["martin"] Extra broker over head but for
strict AMQP I think we need to do it.

 [3:33 pm] partychat0  ["rob"] the naming rules are relaxed for 0-10...

 [3:34 pm] aidan.x.skinner  for 370 and 371?


 [3:34 pm] partychat0  ["rob"] y

 [3:35 pm] aidan.x.skinner  awesome


 [3:35 pm] aidan.x.skinner  QPID-380, I think this is still an issue


 [3:36 pm] partychat0  ["martin"] agreed

 [3:36 pm] partychat0  ["martin"] It has been partially done

 [3:36 pm] aidan.x.skinner  can you add some information about what
you did and what still needs doing? thanks


 [3:36 pm] partychat0  ["martin"] grr

 [3:36 pm] aidan.x.skinner


 [3:37 pm] aidan.x.skinner  QPID-393, rob? how's the alerting in the
refactored broker lookign?


 [3:37 pm] partychat0  ["martin"] hope it is better than M2.1!

 [3:39 pm] aidan.x.skinner  ok, martin, QPID-429, client timeouts


 [3:40 pm] aidan.x.skinner  I thikn we're better than we were, is this
all exposed now?


 [3:40 pm] aidan.x.skinner  Rob: and with QPID-430, does the age
alerting work with the house keeping threads for expiry now?


 [3:41 pm] partychat0  ["martin"] 430 is still an issue and should be
wired to the housekeeping

 [3:41 pm] partychat0  ["rob"] 430 is still an issue

 [3:41 pm] partychat0  ["martin"] 429 is better but we need to bring
the 09/8 and 10 together

 [3:42 pm] partychat0  ["martin"] 431 is my bad!

 [3:42 pm] partychat0  ["martin"] still a problem

 [3:42 pm] partychat0  ["rob"] 393 is not done

 [3:43 pm] aidan.x.skinner  QPID-437, does the c++ broker implement
mandatory yet?


 [3:43 pm] aidan.x.skinner  I sort of presume it must for 0-10 support


 [3:43 pm] partychat0  ["rhs"] I'll check.

 [3:44 pm] aidan.x.skinner  thanks


 [3:44 pm] partychat0  ["rob"] well - it ain't called mandatory anymore

 [3:44 pm] partychat0  ["martin"] and C++ broker doesn't do 08/9:)

 [3:44 pm] partychat0  ["rob"] I would say kill that JIRA

 [3:44 pm] partychat0  ["rob"] since it is talking to 0-8/0-9 compliance

 [3:44 pm] partychat0  [cctrieloff@gmail.com] ack

 [3:44 pm] partychat0  ["rob"] 0-10 compliance if a whole different
kettle of fish

 [3:45 pm] partychat0  ["rhs"] gsim says it does not implement mandatory

 [3:45 pm] aidan.x.skinner  thanks


 [3:45 pm] partychat0  ["rob"] that would be a different defect though

 [3:45 pm] partychat0  ["rhs"] or the 0-10 equivalent (discard-unroutable)

 [3:45 pm] partychat0  ["rob"] I think we should raise non-ambiguous
0-10 complaince defects

 [3:46 pm] aidan.x.skinner  rob: QPID-469?


 [3:46 pm] partychat0  ["rhs"] fine by me

 [3:46 pm] partychat0  ["rob"] what about 462?

 [3:46 pm] aidan.x.skinner  does the new broker record relidvery per
message per queue?


 [3:46 pm] partychat0  ["rob"] what about 462?

 [3:46 pm] partychat0  ["martin"] keep up

 [3:46 pm] partychat0  ["rob"] Aidan: 469 should be fixed

 [3:47 pm] partychat0  ["rob"] 9already fixed that is)

 [3:47 pm] partychat0  ["rob"] No-one mentuioned 462 yet

 [3:47 pm] partychat0  ["martin"] Ah ok.. sorry local context

 [3:47 pm] partychat0  ["martin"] It is a duplicate of the problem in QPid 545

 [3:48 pm] partychat0  ["rob"] My only point on 462 is that as it is
you couldn't change anything... but if you were talking a bout an
auto-delete queue with an exclusive consumer you could actually
discard the messages on arrival at the queue

 [3:48 pm] partychat0  ["rob"] (not the same as an exclusive queue)

 [3:49 pm] aidan.x.skinner  Did anybody ever fix QPID-494? (broker
doesn't set exit code when it fails to start)


 [3:49 pm] partychat0  ["martin"] 494 : nope

 [3:49 pm] aidan.x.skinner  yeah, just realised i could check that myself


 [3:49 pm] partychat0  ["martin"] 462 . could you not discard message
on arrival to queue if it was persistent?

 [3:50 pm] aidan.x.skinner  ok, QPID-497, pything test for codec.py. rhs?


 [3:50 pm] partychat0  ["martin"] Jumping back to 469

 [3:51 pm] partychat0  ["martin"] I QueueEntry delegates to the
message for redelivered.

 [3:51 pm] partychat0  ["martin"] so I'd say it is still an issue.

 [3:52 pm] partychat0  ["rob"] oops - so it does

 [3:52 pm] partychat0  ["rob"] that should be fixed then

 [3:52 pm] partychat0  [cctrieloff@gmail.com] rhs: just goy up from
desk, talking to justin on an issue

 [3:53 pm] aidan.x.skinner  ok, i'll skip the python ones then


 [3:54 pm] aidan.x.skinner  rob: can you reopen that one and paste
this conversation into it?


 [3:54 pm] partychat0  ["rob"] which one 469?

 [3:54 pm] aidan.x.skinner  yeah


 [3:54 pm] partychat0  ["rhs"] back now

 [3:54 pm] partychat0  ["rhs"] QPID-497 can be closed

 [3:55 pm] aidan.x.skinner  ok, how about 498?


 [3:55 pm] partychat0  ["rhs"] QPID-498 can be closed as well

 [3:55 pm] partychat0  ["rhs"] QPID-506 can be also be closed

 [3:55 pm] partychat0  ["rhs"] QPID-518 as well

 [3:56 pm] partychat0  ["rhs"] QPID-519 can be rolled up with any
other general documentation issues

 [3:56 pm] partychat0  ["rhs"] or just closed

 [3:56 pm] aidan.x.skinner  ok, can   you make those changes (I got as
far as 506)


 [3:57 pm] aidan.x.skinner  Martin: 509 I think is still a problem, y/n?


 [3:57 pm] partychat0  ["martin"] indeed

 [3:57 pm] partychat0  ["rob"] yes

 [3:57 pm] partychat0  ["rob"] we should really fix that!

 [3:57 pm] aidan.x.skinner  please set priorty appropriately then


 [3:57 pm] aidan.x.skinner  "major" is actually "medium"


 [3:58 pm] aidan.x.skinner  rhs: about QPID-519?


 [3:58 pm] partychat0  ["rhs"] aidan: yes?

 [3:58 pm] aidan.x.skinner  closeable?


 [3:59 pm] partychat0  ["rhs"] aidan: yes

 [3:59 pm] aidan.x.skinner  also, QPID-522, does ant generate javadoc for us?


 [3:59 pm] partychat0  ["rhs"] good question, lemmie check

 [4:00 pm] partychat0  ["rhs"] we should really add javadoc generation
to an automated build somewhere

 [4:00 pm] partychat0  ["rob"] we should really add javadoc

 [4:00 pm] partychat0  [rajith77@gmail.com] rhs we could do that in CC
and we can add a link to it in our wiki

 [4:01 pm] partychat0  ["rhs"] it would be nice to have it auto
publish to somewhere public

 [4:01 pm] aidan.x.skinner  ok, anybody know anything about QPID-539 -
does headersexchange implement isBound properly now?


 [4:01 pm] partychat0  [rajith77@gmail.com] similar to the way we have
a link to the rpms

 [4:01 pm] partychat0  ["rob"] skipping over 524?

 [4:01 pm] aidan.x.skinner  yeah, i don't want to start that discussion


 [4:01 pm] aidan.x.skinner  and the next few are c++ thigns i know
aren't implemented


 [4:01 pm] partychat0  ["rob"] I think we should just close that JIRA

 [4:01 pm] partychat0  ["martin"] 539 no

 [4:01 pm] partychat0  ["rhs"] aidain: "ant doc" generates javadoc
with a whole lot of warnings

 [4:02 pm] partychat0  ["rob"] (524 hould be closed, that is)

 [4:02 pm] aidan.x.skinner  rhs: shock


 [4:02 pm] partychat0  ["rob"] since a) the situation is now even worse

 [4:02 pm] partychat0  ["rob"] and  we currently have no plans to do
anything about it

 [4:02 pm] aidan.x.skinner  ok


 [4:03 pm] aidan.x.skinner  545 is still an issue, yes?


 [4:03 pm] partychat0  ["martin"] yes

 [4:03 pm] partychat0  ["rob"] Yes - there is now an alternative however

 [4:03 pm] aidan.x.skinner  please add details of said alternative to jira


 [4:03 pm] partychat0  ["rob"] i.e. use selectors on bind between
queue and exchange

 [4:04 pm] aidan.x.skinner  martin: did you not do QPID-570?


 [4:04 pm] partychat0  ["martin"] two ticks was in the page fold

 [4:04 pm] partychat0  ["rob"] aidan: I think the JIRA as is still
stands i think we need a new JIRA on utilising the binding option

 [4:05 pm] partychat0  ["martin"] a yes/no.. yes we did but it was
done in docbook and no because we've not maintained it

 [4:05 pm] aidan.x.skinner  so no to both, rob, can you raise the new one then?


 [4:06 pm] aidan.x.skinner  rhs: QPID-572, still a problem?


 [4:06 pm] partychat0  ["rob"] I could  Let me do that now...

 [4:06 pm] aidan.x.skinner  Was there a test written for it?


 [4:07 pm] aidan.x.skinner  rob: thanks


 [4:07 pm] aidan.x.skinner  rhs: my memory of that is hazy, but I
*think* it was fixed...


 [4:10 pm] aidan.x.skinner  rhs: same for 573


 [4:10 pm] partychat0  ["martin"] 572 is probably less of an issue
with the replacement of the CSDM

 [4:10 pm] partychat0  ["martin"] but as it was a narley race
condition to start with it might be hard to test for

 [4:11 pm] partychat0  ["martin"] s/narley/gnarley/

 [4:11 pm] partychat0  "martin" meant but as it was a gnarley race
condition to start with it might be hard to test for

 [4:11 pm] aidan.x.skinner  martin: what news of 578?


 [4:13 pm] partychat0  ["martin"] I think it is still pending

 [4:13 pm] aidan.x.skinner  also, QPID-580, I'm unclear as to what the
coments mean


 [4:15 pm] partychat0  ["martin"] Just looking at code

 [4:15 pm] partychat0  ["martin"] for 578

 [4:17 pm] aidan.x.skinner  right, and 602? I presume we still need to
add that test?


 [4:18 pm] aidan.x.skinner  rhs: how about QPID-641?are you testing
against 0-10 field table encoding now?


 [4:19 pm] partychat0  ["rhs"] aidan: yes

 [4:19 pm] partychat0  ["rhs"] aidan: that can be closed

 [4:19 pm] aidan.x.skinner  sweet


 [4:20 pm] aidan.x.skinner  anybody know anything about QPID-656?
it's a 0-10 java client / C++ broker bug about x-match


 [4:21 pm] partychat0  [rajith77@gmail.com] no idea

 [4:21 pm] aidan.x.skinner  rob: QPID-659, is selector performance in
the new broker better / acceptable?


 [4:21 pm] partychat0  ["rob"] it should be

 [4:22 pm] partychat0  ["rob"] certainly the bug described in there
should be gone

 [4:22 pm] aidan.x.skinner  is there a test?


 [4:22 pm] partychat0  ["rob"] for 659 - no

 [4:22 pm] partychat0  ["rob"] but selectors work differently now...

 [4:22 pm] aidan.x.skinner  ok, i'm commenting on the jira and leaving it now


 [4:22 pm] partychat0  ["rob"] I think that can be closed

 [4:22 pm] partychat0  ["rob"] it talks about pre-delivery queues

 [4:22 pm] partychat0  ["rob"] which no longer exist

 [4:23 pm] aidan.x.skinner  yeah, but it's really about selector performance


 [4:23 pm] aidan.x.skinner  which is a major thing for at least one of our users


 [4:24 pm] partychat0  ["rob"] no it's not (about performance)

 [4:24 pm] aidan.x.skinner  rhs: how about 669?


 [4:24 pm] partychat0  ["rob"] if you read the JIRA it's about an
inifinite loop

 [4:24 pm] partychat0  ["rob"] If a message that doesn't match a the
consumers selector arrives on the queue the asynchronous delivery
manager will not terminate.

 [4:24 pm] partychat0  ["rob"] Due to the use of a pre-delivery queue
a message that is not desired by any consumer will stick in the queue.
This will then cause the async delivery process to loop consuming a
large amount of CPU. The async process will not stop because there are
'message on the queue' and 'active consumers'.

 [4:24 pm] aidan.x.skinner  yeah, but the other option would be to
raise a jira to write a test to test that it's faster


 [4:25 pm] partychat0  ["rob"] I think there is room for a JIRA on
wiriting performance tests for selectors

 [4:25 pm] partychat0  ["rob"] but that is a completely separate issue

 [4:25 pm] partychat0  ["rob"] the actual performace of selecting will
be no better

 [4:25 pm] partychat0  ["rob"] but there is no longer an inifinite loop bug

 [4:25 pm] aidan.x.skinner  ok


 [4:25 pm] partychat0  ["rob"] (or if there is, not the same one  )

 [4:26 pm] aidan.x.skinner  QPID-1169 filed


 [4:27 pm] aidan.x.skinner  rhs: also, is   QPID-673 still an issue?


 [4:27 pm] aidan.x.skinner  (talking about needing a Session interface)


 [4:27 pm] aidan.x.skinner  and 675 to 676?
 [4:29 pm] aidan.x.skinner  martin: QPID-677? that's presumably
needing upped to critical?
 [4:30 pm] partychat0  ["martin"] There needs to be a broker test
written for it
 [4:30 pm] partychat0  ["martin"] IIRC we have made changes that fix this
 [4:30 pm] partychat0  ["martin"] it isn't critical
 [4:30 pm] partychat0  ["martin"] The broker shouldn't be editing the
properties anywaay
 [4:33 pm] aidan.x.skinner  ok
 [4:40 pm] aidan.x.skinner  ok, i'm drawing a line here
 [4:41 pm] aidan.x.skinner  well done everyone, we closed out 20 jiras
[4:41 pm] aidan.x.skinner  I'll send mail about picking this up again later

Re: Jira decrufting bug day hugathon party

Posted by Martin Ritchie <ri...@apache.org>.
2008/7/8 Aidan Skinner <ai...@apache.org>:
> On Mon, Jul 7, 2008 at 10:45 AM, Aidan Skinner <ai...@apache.org> wrote:
>
>> with M3 rapidly descending upon us, it seems prudent to have an
>> all-day party on #qpid on partychat to dung it out a bit and resolve
>> old things. How does 1000 EDT / 1500 BST / 1400 UTC suit people?
>
> Silence is aquiescene, bug triage super cleanup happy funtime will
> begin in 3 hours!
>
> - Aidan
> --
> Apache Qpid - World Domination through Advanced Message Queueing
> http://cwiki.apache.org/qpid

Sorry, I have a rogue filter that sucks away all misc emails with
'JIRA' in the title. Will have to adjust as it is clearly out of
control!
-- 
Martin Ritchie

Re: Jira decrufting bug day hugathon party

Posted by Aidan Skinner <ai...@apache.org>.
On Mon, Jul 7, 2008 at 10:45 AM, Aidan Skinner <ai...@apache.org> wrote:

> with M3 rapidly descending upon us, it seems prudent to have an
> all-day party on #qpid on partychat to dung it out a bit and resolve
> old things. How does 1000 EDT / 1500 BST / 1400 UTC suit people?

Silence is aquiescene, bug triage super cleanup happy funtime will
begin in 3 hours!

- Aidan
-- 
Apache Qpid - World Domination through Advanced Message Queueing
http://cwiki.apache.org/qpid