[rabbitmq-discuss] Thoughts from a new user

Shane Witbeck shane at digitalsanctum.com
Sat Sep 18 15:09:21 BST 2010

A big +1 on all the points brought up here especially improved usability of
the website and docs. I assume the docs will eventually be more typical of
the springsource projects :)

I also much prefer homebrew for Mac installs over macports.


On Sep 18, 2010, at 9:47 AM, Adam Nelson <adam at varud.com> wrote:


Thanks for the great replies, I've included comments below:

> [...]
> >  * This newsgroup format is terrible.  Please move to Google Groups.
> You can browse the mailing list at
> <http://groups.google.com/group/rabbitmq-discuss>, and through various
> other mailing list to web gateways.  What makes this arrangement
> terrible for you?  Not being able to post through them, or something
> else?
> Signup is difficult, it's one more username for me to get, manage, and
maintain.  I (and I presume 80% of the others here) already have a Gmail
account - so posting for the first time wouldn't require going through
several steps. The first time I posted, it was refused because the web
interface apparently isn't integrated well with the email interface.  I had
to sign up again the old fashioned way (via email).  Maybe it was a failure
on my end but it reminded me of 1998 in every way.

Searching the archive is also significantly slower than on Google Groups.

 >  * The code is very difficult to get at.  Please move to Github (or
> > BitBucket).  I see that you're using Mercurial already, so BitBucket is
> the
> > obvious choice.  I think GitHub is way more feature rich but if you're
> not
> > willing to move to Git, that won't work of course.
> Could you explain more about how the code is very difficult to get at?
> It can be browsed online through the standard Mercurial web interface at
> <http://hg.rabbitmq.com/>, and the process of cloning the repos would be
> very similar under github and bitbucket.  I appreciate that github and
> bitbucket have some advantages, but what, from your perspective, are the
> key ones that would apply to RabbitMQ?

For a core developer, you probably already have a cloned hg copy.  I'm not a
core developer.  My use for the code is to examine documentation and places
where an exception is thrown.  I'm not going to be patching the code, but
instead posting a bug report if something like that comes up.  Being able to
access the code readily through a browser is key to that experience.

If you want more traction in the wider community outside of queues and
brokers (i.e. Python programmers writing websites), RabbitMQ needs to make
things more accessible more easily for the user.


> >  * The documentation is not version-specific.  This has caused me
> enormous
> > problems (specifically with set-permissions, which is why I'm in the mode
> to
> > write this message at all).  Please move to a platform that supports
> > versioned documentation better.  I don't know the best solution to this
> > exactly - maybe Sphinx or just a wiki with a url structure that supports
> > multiple versions?
> The principal documentation for set_permission is the rabbitmqctl man
> page.  It's true that we only make the current versions of the man pages
> available on the web site.  Would your problems have been avoided if we
> published older versions of the man pages on the web site?
> Yes.  Ubuntu is only on the 1.7.x series and the stable series on your site
is 2.1.x

> The web site content is maintained in Mercurial alongside our codebase.
> This is convenient in a number of ways for us (e.g. being able to handle
> code changes and the corresponding web site documentation changes in the
> same workflow).  So it's conceivable that we could publish multiple
> versions of the documentation from Mercurial on the web site.  This
> would however require us to draw more of a distinction between reference
> documentation and other types of information, the former tending to be
> much more strongly version-specific.  But maybe that's a good idea
> anyway.
> Django does it like that:

> >  * Where are the open tickets?  It appears that all bugs are going
> through
> > the mailing list - it's really hard on the users to not have an
> > easy-to-search ticket system.  Launchpad could work or BitBucket's issue
> > system, or Redmine, or Trac?
> The rabbit team's development work is tracked in bugzilla, but that
> bugzilla instance is not currently public.  We will make it public at
> some point, though doing so is not quite as straightforward as it might
> first seem.
> Bugzilla might not be as modern or attractive as some of the issue
> trackers you mention, but it is very featureful, and ours is integrated
> into the rest of our development infrastructure.

Modern and attractive is important.  I understand that there is a (large)
transaction cost tied to moving but it's an important one to swallow.  If
you're huge like Mozilla and are using Bugzilla, I understand that it's
simply too difficult to change horses.  However if you go public with
Bugzilla, you're going to get twice the duplicates (because searching is so
painful) and half the real useful user feedback (because posting is so

Obviously, you guys run the show.  I'm just hoping that as one of the early
users of your software in production who isn't otherwise tied to the
messaging community, that you'll take my comments to heart.  Most people in
my situation a year from now will choose the AMQP broker that has the best
documentation and the most transparent release, maintenance, and setup
processes - performance is secondary.  I see ZeroMQ successfully tackling
those issues well and I just think we'd all benefit from a stronger


> David
> --
> David Wragg
> Staff Engineer, RabbitMQ
> SpringSource, a division of VMware


rabbitmq-discuss mailing list
rabbitmq-discuss at lists.rabbitmq.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rabbitmq.com/pipermail/rabbitmq-discuss/attachments/20100918/5aaf3df3/attachment-0001.htm>

More information about the rabbitmq-discuss mailing list