Hi Andrew, Thanks on the CI setup, I think a separate list would be good for the traffic it generates.
Be really good to have a shared view of the tests running etc for the project. Cheers, Marnie On Tue, Apr 19, 2011 at 10:14 PM, Andrew Kennedy < andrewinternatio...@gmail.com> wrote: > 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 > >
