I agree with most of Andrew Kennedy's comments. Source dist we should do, but for most users it's a hurdle they don't want to deal with - we should ship built packages too.
Across the project we have a range of dev platforms we can leverage to setup automated testing for the kind of smoke tests required on a platform by platform basis. For our next release, I should have access to a dedicated Windows test env which we could use for dist testing etc, along with RHEL 4,5,?6 and AIX and Solaris 10. Marnie On Tue, Nov 23, 2010 at 2:13 PM, Alan Conway <[email protected]> wrote: > On 11/23/2010 08:30 AM, Jonathan Robie wrote: > >> On 11/22/2010 05:44 PM, Andrew Kennedy wrote: >> >>> On 22 Nov 2010, at 18:00, Rajith Attapattu wrote: >>> >>>> On Mon, Nov 22, 2010 at 11:09 AM, Rajith Attapattu >>>> >>> . >> >>> 1) Have we packaged our products in a way that is useful for our target >>>> users ? >>>> >>> >>> 1. I agree that providing a full, DIY source bundle is something that >>> should definitely be provided, but in addition to other downloads. I >>> don't see why both models can't coexist? >>> >>> 2. It should be alongside componentised or modularised binary downloads. >>> The installable artifacts are the brokers and the management >>> console/command line tools, which should be available as platform >>> specific binaries, installable packages of various kinds, and as a DIY >>> source tarball, for Java and C++. >>> >> >> I like this as an ideal, but only if we actually do the level of testing >> needed >> to ensure that each component is usable as is. >> >> Before we checked RC2, we didn't notice that many of the README.txt files >> give >> instructions that don't work for the packages they apply to, or that the >> command >> line management tools are available only in the full source download, or >> that >> the README.txt for the Java client actually was intended for the broker. >> >> Are we going to commit to testing each of these packages? If we're going >> to ship >> them, we need a test plan that's a little more sophisticated than "if >> nobody >> notices a problem by a given date, or nobody fixes a known problem that >> has been >> noticed, then it's apparently good enough". >> >> If we're not going to commit to better testing and better consistency, >> it's >> better to ship only the full source distribution. >> >> > Shipping the full source distro does nothing to address the testing > problem. It is just as much work to build each of the individual pieces of > source tree and test them as it is to test the individual packages. > > Also note that the C++ build (maybe others) actually builds generated > source code, config scripts etc. that go into the distro so building the C++ > tree in source form is *more* difficult (has more dependencies) than > building the distro. Also the READMEs etc. are written from the assumption > that the user has a distro, not a source tree. I'm not saying we can't do a > pure source distribution but there is work required on the C++ build system > if we do. > > > --------------------------------------------------------------------- > Apache Qpid - AMQP Messaging Implementation > Project: http://qpid.apache.org > Use/Interact: mailto:[email protected] > >
