<html><head></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><div>I totally agree as well.</div><div><br></div><div>The mailing list is/was a pain (I am subscribed to many lists through google and its become lovely to manage all those list through it), and I much prefer the archive/search facility on Google groups.</div><div><br></div><div>GIthub in my opinion is just excellent in so many ways right now, its browsing of code and the related documentation is really nice, the forking and community aspects are just fantastic. But I would rather have solidly built packages than run from the bleeding edge but I would read any documentation on there.</div><div><br></div><div>The documentation is something that really needs attention, I actually started putting documentation on my own Wiki based upon what I found for the version I was running, bits pulled from the newsgroup that are more up to date than the actual website just to be able to get somewhere. Of course Django (mentioned below) has one of the most respected documentation setups of any project that I have come across. My best example of how not to do things is VMWare - bad forum software, badly documented (forum is the place for hacks), - although fine if you pay the big bucks and get support its become a barrier to entry for uptake - I hope they are not an influence.</div><div><br></div><div>And I agree Homebrew is much nicer than MacPorts (I won't have that installed on any machine that I use) if you are developing on OSX.</div><div><br></div><div>Tim.</div><div><br></div><br><div><div>On 18 Sep 2010, at 16:09, Shane Witbeck wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><div bgcolor="#FFFFFF"><div>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 :)</div><div>
<br></div><div>I also much prefer homebrew for Mac installs over macports.<br><br>-Shane<div><br></div></div><div><br>On Sep 18, 2010, at 9:47 AM, Adam Nelson <<a href="mailto:adam@varud.com">adam@varud.com</a>> wrote:<br>
<br></div><div></div><blockquote type="cite"><div>David,<div><br></div><div>Thanks for the great replies, I've included comments below:<br><br><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
> [...]<br>
<div class="im">> * This newsgroup format is terrible. Please move to Google Groups.<br>
<br>
</div>You can browse the mailing list at<br>
<<a href="http://groups.google.com/group/rabbitmq-discuss" target="_blank"></a><a href="http://groups.google.com/group/rabbitmq-discuss">http://groups.google.com/group/rabbitmq-discuss</a>>, and through various<br>
other mailing list to web gateways. What makes this arrangement<br>
terrible for you? Not being able to post through them, or something<br>
else?<br>
<div class="im"><br></div></blockquote><div>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.</div>
<div><br></div><div>Searching the archive is also significantly slower than on Google Groups.</div><div><br></div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class="im">
> * The code is very difficult to get at. Please move to Github (or<br>
> BitBucket). I see that you're using Mercurial already, so BitBucket is the<br>
> obvious choice. I think GitHub is way more feature rich but if you're not<br>
> willing to move to Git, that won't work of course.<br>
<br>
</div>Could you explain more about how the code is very difficult to get at?<br>
It can be browsed online through the standard Mercurial web interface at<br>
<<a href="http://hg.rabbitmq.com/" target="_blank"></a><a href="http://hg.rabbitmq.com/">http://hg.rabbitmq.com/</a>>, and the process of cloning the repos would be<br>
very similar under github and bitbucket. I appreciate that github and<br>
bitbucket have some advantages, but what, from your perspective, are the<br>
key ones that would apply to RabbitMQ?<br></blockquote><div><br></div><div>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.</div>
<div><br></div><div>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.</div>
<div>
<br></div><div><a href="http://github.com/zeromq/zeromq2"></a><a href="http://github.com/zeromq/zeromq2">http://github.com/zeromq/zeromq2</a></div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class="im"><br>
> * The documentation is not version-specific. This has caused me enormous<br>
> problems (specifically with set-permissions, which is why I'm in the mode to<br>
> write this message at all). Please move to a platform that supports<br>
> versioned documentation better. I don't know the best solution to this<br>
> exactly - maybe Sphinx or just a wiki with a url structure that supports<br>
> multiple versions?<br>
<br>
</div>The principal documentation for set_permission is the rabbitmqctl man<br>
page. It's true that we only make the current versions of the man pages<br>
available on the web site. Would your problems have been avoided if we<br>
published older versions of the man pages on the web site?<br>
<br></blockquote><div>Yes. Ubuntu is only on the 1.7.x series and the stable series on your site is 2.1.x </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
The web site content is maintained in Mercurial alongside our codebase.<br>
This is convenient in a number of ways for us (e.g. being able to handle<br>
code changes and the corresponding web site documentation changes in the<br>
same workflow). So it's conceivable that we could publish multiple<br>
versions of the documentation from Mercurial on the web site. This<br>
would however require us to draw more of a distinction between reference<br>
documentation and other types of information, the former tending to be<br>
much more strongly version-specific. But maybe that's a good idea<br>
anyway.<br>
<div class="im"><br></div></blockquote><div>Django does it like that:</div><div><a href="http://docs.djangoproject.com/en/1.2/topics/db/models/"></a><a href="http://docs.djangoproject.com/en/1.2/topics/db/models/">http://docs.djangoproject.com/en/1.2/topics/db/models/</a></div>
<div><a href="http://docs.djangoproject.com/en/dev/topics/db/models/"></a><a href="http://docs.djangoproject.com/en/dev/topics/db/models/">http://docs.djangoproject.com/en/dev/topics/db/models/</a></div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div class="im">> * Where are the open tickets? It appears that all bugs are going through<br>
> the mailing list - it's really hard on the users to not have an<br>
> easy-to-search ticket system. Launchpad could work or BitBucket's issue<br>
> system, or Redmine, or Trac?<br>
<br>
</div>The rabbit team's development work is tracked in bugzilla, but that<br>
bugzilla instance is not currently public. We will make it public at<br>
some point, though doing so is not quite as straightforward as it might<br>
first seem.<br>
<br>
Bugzilla might not be as modern or attractive as some of the issue<br>
trackers you mention, but it is very featureful, and ours is integrated<br>
into the rest of our development infrastructure.<br></blockquote><div><br></div><div>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 painful). </div>
<div><br></div><div>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 RabbitMQ:</div>
<div><br></div><div>Thanks,</div><div>Adam</div><div><br></div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<br>
David<br>
<font color="#888888"><br>
--<br>
David Wragg<br>
Staff Engineer, RabbitMQ<br>
SpringSource, a division of VMware<br>
</font></blockquote></div><br><br clear="all"><br>-- <br><br></div></div></blockquote></div></blockquote></div><div>
</div>
<br></body></html>