On 19 April 2011 17:55, Marnie McCormack <marnie.mccorm...@googlemail.com> wrote: > I think regular, on schedule releases are key for an Apache project - > without them we are seen as less credible than other OS projects in the > messaging space. > > We have historically really struggled to get our releases out on time/as > planned and across the ?5 years we've been going we have made (I think) 9 > releases including those from incubator. > > We need to get faster and not be holding up the greater number of fixes for > the last couple in each release. Only if we get quicker can we more rapidly > evolve the product Apache users actually get to use :-) > > We also should really discuss testing as a group - we currently have a > non-defined release gateway for testing, which lets us down somewhat. > > Just my tuppence - based on reading non-Apache Qpid people's assessments of > messaging products in the OS space.
+1, see below for update regarding automated testing during CI. >> > I'd like to hear some thoughts about this from the community. >> > My personal preference is to do an errata release for >> > QPID-3214 & QPID-3216 (and any other serious issues like >> > that). What do you guys think ? >> >> I tend to view errata/hotfix as services that downstream support >> providers handle. You can use up a lot of time and effort going down >> that road. Errata and hotfix releases are a red herring. If we get our continuous integration process right, we should be able to provide snapshot nightly releases from trunk, which will give people the fixes they require. If there is a glaring security hole found in the broker then that may warrant an off-cycle release, but keeping to a schedule of releases is a better plan. >> If QPID-3214 and 3216 are serious issues I would prefer to hold 0.10 for >> the fixes. The word "deadlock" in the jira subject seems serious, but >> I'm wondering how likely it is a user will hit it if it hasn't been >> found before. Fair point, but I would need to investigate further, maybe Rajith has more information? These issues were apparently found when he ran the tests under the C++ profile, but they didn't show up under any of the Java profile system test runs I did when I was made the change that seems to have caused QPID-3214. Also, I believe that this issue occurs during QueueBrowser failover, and the tests for this are, in fact, disabled for Java profiles. The code involved is quite brittle, and I know there are a few more threading and locking issues either there or nearby. These intermittent issues are always difficult to diagnose, so it's good that we have a way to reproduce some of them now. I'd personally mark these as blockers for the next release, and make sure that we have better test coverage during 0.12 development. I know Rajith is looking at this, and I will as well, to determine if there *is* a quick fix possible. Similar statements hold for QPID-3216, as well ;( On that subject, the Java continuous integration is running happily on the ASF Hudson instances, however it does *not* run the C++ builds or tests, since we cannot get the right libraries installed across the whole Hudson cluster. Fortunately, my employer, Cloudsoft, has kindly agreed to provide some Amazon EC2 instances for the project. I have installed Hudson on one currently, and have got the C++ and Java system test suites running. Once I get a few issues ironed out, and also start the clustered system tests running as well, we should have a much better view of the test coverage, and these sorts of problems are less likely to occur. If interested, lok at this temporary URL (I will sort out a static IP and DNS shortly) below: http://ec2-46-137-19-127.eu-west-1.compute.amazonaws.com:8080/ Once the CI system is stable, is everyone happy for me to point the e-mails it gereates at this list, or do you think we need another, bu...@qpid.apache.org perhaps? Cheers, Andrew. -- -- andrew d kennedy ? cloudsoft monterey : http://www.cloudsoftcorp.com/ ; --------------------------------------------------------------------- Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
