Excuse the brain dump, but there are so many emails already that rather than send 15 different responses I'm just going to write one email. I may have also forgotten many of the things I thought when reading the various earlier emails :)
I think that having a single source archive is fine since that is what actually constitutes an Apache release. I am quite against having *only* that single source archive, which is what I think is being suggested by some of the emails in the thread, although perhaps I'm getting the round end of the stick about that. At the very least there should continue to be binary convenience packages for components in those languages where binary is the widely expected delivery form (i.e. Java), and I would consider it somewhat odd to suggest doing otherwise in an email thread titled 'How easy is it to get Qpid going?'. You can get the 0.8 RC3 binaries of the Java broker and client up and running inside 30 seconds; you can't do that with the source. I'd also consider what other projects in our field do in this area, e.g. ActiveMQ and RabbitMQ. If anything we should really have more binary in this case (i.e. Maven <shudder> repo artifacts), not less. I don't think having a single source-only download would really mean we would have all that much less testing/checking/documenting to do at present: you still have to build and test all the bits even in a source release, and I'm fairly sure a lot of the READMEs etc that were out of date and got updated in the last week were still out of date no matter which archive they were in. I think one of the main reason these types of issues arise is that because we release so infrequently we often don't bother to even consider the trivial things like 'how will a user install this' as there is such little urgency to keeping them up to date (I think it's over 3 months since the idea of doing this release was floated)...and then they eventually get just forgotten about. Another issue is that we often don't use the codebase in a way that remotely resembles what users would want to do once they have their hands on release artifacts (source or binary) until it is time to do a release, we should at least try to consider that more often (more on this below targeted specifically at the Java tree). I have no problem offering compilation binary bundles that include a variety of clients, brokers, tools, etc (even if it is *all* of them, every single thing we produce in immediately executable form)...however I think this should be a simple tar/zip composed of units that could otherwise be shipped individually (whether we chose to do so or not). The qpid-java-<version>.tar.gz binary compilation package is an example of what not to do and it should die. It's a horrible mashup of jars and scripts, bundles things that can't be used in any way, has included components that can't even work with any other thing in the same package, and presents something largely incomprehensible to an end user. That particular case basically arises because it constitutes what gets output by the Java build system in normal use; Rafael has mentioned in the past that the release binary we ship should closely match what we use as developers and I agree, thus I think that *we* need to start using build artifacts/layouts that more closely resemble what a user might actually be doing with the output. For example, have the standard build output produce a directory for the client module output with only the client lib/deps in it and not everything for every java component. A binary release compilation of the java components could then be a simple tar of that output, effectively including the contents of what currently gets shipped as qpid-java-client-<version>.tar.gz and qpid-java-broker-<version>.tar.gz and <other java component tar> in nice separate directories that are basically tested day in day out. We obviously have to extend the documentation efforts prompted by 0.8 RC2 to make the downloads easier to actually use, whatever they are. The Java documentation in general is obviously a clear offender and is something we should work on. I have tried to make the individual Java component artifacts more useable in this release, allowing the broker to be run out-of-the-box, as well as adding the examples and README documentation to the client bundle and upgrading SLF4J to make it usable out-of-the-box without adding/configuring a logging implementation. We should actually undertake previously proposed ideas such as having sandbox and attic areas in the repo to allow streamlining what is actually getting released from trunk in future; if it isn't being actively developed there is no need to keep generating artifacts and if it isn't even working there is no need to be shipping effectively unused dependencies. I think I'll stop now, I don't have a publishing deal for this :) Robbie > -----Original Message----- > From: Rajith Attapattu [mailto:[email protected]] > Sent: 22 November 2010 16:09 > To: [email protected] > Subject: How easy is it to get Qpid going ? > > Hi All, > > Based on the questions asked on our user list and feedback from > customers > etc.. it seems that we have plenty of room to improve when it comes to > ease > of use and documentation. > Ease of use is one that directly impacts the first impression about any > new > product. > > I firmly believe this is something that needs to be one of the top > priorities (if not the top most) for our next release. > Perhaps it's time for us to take a step back and see if, > > 1) Have we packaged our products in a way that is useful for our target > users ? > 2) How easy is it for folks to download an install our products ? > 3) How easy is it for people to run the examples and get it going? > 4) Have we organized our documentation properly? > 5) Have we got enough documentation to cover atleast the basic aspects? > 6) Have we got enough documentation to cover the topics that people are > interested once they get the basics going? > 7) Are we releasing frequently enough for users to rely on us to ensure > that > critical bugs are fixed ? > 8) Do we as a project have a process that defines how we handle a > critical > issue after a release ? > > I am positive that our community (both developers and end users) has a > lot > of good ideas. > I am quite keen on hearing suggestions/comments about the above topics. > I will start by replying to my email with what I think about the above > questions :) > > Regards, > > Rajith Attapattu > Red Hat > http://rajith.2rlabs.com/ --------------------------------------------------------------------- Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:[email protected]
