db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rick Hillegas <Richard.Hille...@Sun.COM>
Subject Re: Getting ASF machine resources for Apache Derby
Date Mon, 08 Jun 2009 13:51:58 GMT
Hi Kristian,

Some comments inline...

Kristian Waagan wrote:
> Hello,
> I'd like to investigate whether the Apache Derby project can get some 
> ASF machine resources assigned, because I feel we have some tasks that 
> could be better performed in a project environment (as opposed to a 
> user environment).
I agree that moving our continuous integration environment onto 
community machines would be a good idea. That includes the 
commit-triggered build/test cycles, nightly build/test cycles, and doc 
> One of the good things about a project environment, is that more 
> people have the opportunity to fix problems and get involved. It is 
> not clear to me yet whether access to the resource should be limited 
> to PMC members, committers or a different group of contributers.
If this work is scoped to the Derby project, it makes sense to me to 
limit access to Derby committers.
> The initial issue I'd like to solve is building and publishing the 
> manuals. This process is currently pretty "closed" (i.e., just a few 
> persons can monitor and fix problems with the process).
> Other things on the list of possible tasks:
> - Clover (needs license, ASF might have one we can use)
>   Code coverage and intelligent test selection on commits.
>   A full run of the test suite on a weekly basis?
> - Hudson
>   Continuous builds. Note that Ole is doing a great job of this today 
> and I'm not suggesting stopping that effort!
>   I'm not sure if we can expect to run the full test suite, but maybe 
> we can run a small subset of the tests, and it looks exciting to 
> combine Clover and Hudson.
I think you're suggesting that Ole migrate the build/test framework from 
Sun machines onto a community machine?
> Let me spend a few sentences on why I'm suggesting Clover.
> Clover is a code coverage tool. It uses source level instrumentation 
> to get the information it needs when running tests. Compilation is 
> handled through the regular project ant scripts (i.e., that will take 
> care of using the correct compiler etc).
> As far as I'm aware, it can answer questions like [1]:
> - what is our overall code coverage?
> - which test(s) contribute to the coverage of this code?
> - which tests should be rerun first when we change this part of the 
> code? (i.e. which tests are most likely to fail after a code change)
> - which areas of the code should be better tested? (complexity/size 
> and missing coverage)
Clover sounds like a good tool. But I'd recommend separating the Clover 
discussion into a separate email thread.
> I think we may be able to get a Solaris zone to perform one or more of 
> these tasks.
> The first step would involve at least the following steps:
> 1) Obtain a Solaris zone.
> 2) Agree on who should have access to the zone (PMC chair will be the 
> initial owner).
I don't understand why the PMC chair needs to be so heavily involved. I 
can promise you that this PMC chair will pass the responsibility onto 
more knowledgeable people in a New York minute!

> 3) Initial configuration of the zone (software, users, etc).
> 4) Describe and implement the automation task for building and 
> publishing the manuals.
> 5) Figure out the usage restrictions on the zone (if any).
> I volunteer to investigate this and hopefully get a zone created.
> Before I take this to the PMC and/or infra, I'd like some feedback 
> from the community.
> Is this something that will add value to the project?
> Regards,

View raw message