db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Kristian Waagan <Kristian.Waa...@Sun.COM>
Subject Re: Getting ASF machine resources for Apache Derby
Date Mon, 08 Jun 2009 15:54:38 GMT
Rick Hillegas wrote:
> 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 
> builds.

Hi Rick,

I think I would remove tests from that list, at least initially. We'll 
be getting a zone on a shared machine here, and in any case the tests 
will only be run on a single platform. I think the tests are currently 
being run on a large number of platforms (Ole is the one publishing most 
test results, there are probably others out there too).

>> 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).
> +1
>>
>> 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?

No, not really.
I'm not sure Ole's extensive test runs can ever be migrated to ASF 
infrastructure, unless somebody pays ASF a lot of money to buy equipment :)
The things I suggested above are aimed at giving the community feedback 
on problems as fast as possible, and I imagined this would be something 
on the side of what is being done today. My plan was to use existing 
software and a little scripting.
I think Ole has to answer if anything of his framework can easily be 
ported to ASF infrastructure, and if that is something he wants to consider.
My initial focus is on opening up the process of building and publishing 
the manuals, and possibly implementing continuous builds.

>
>>
>> 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.

That's fine. It will be a later step in any case.
I will go ahead and ask about the license situation though. If we can't 
get a license, there's no point continuing the process.

>>
>> 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!

I think this is ASF policy, but I'll check if it has to be the PMC chair 
or just a PMC member.
If the chair has to do anything, I expect it will only be formalities 
and I'll help you out as much as I can.


-- 
Kristian
>
> Thanks,
> -Rick
>> 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,
>


Mime
View raw message