RFR: 7133124 Remove redundant packages from JAR command line

[Georges Saab]

On 28 jan 2012, at 09:46, Kelly O'Hair wrote:

> 
> On Jan 27, 2012, at 9:52 PM, Georges Saab wrote:
> 
>> 
>> On 27 jan 2012, at 12:40, Kelly O'Hair wrote:
>> 
>>> 
>>> On Jan 26, 2012, at 2:47 PM, Georges Saab wrote:
>>> 
>>>>> As long as we target both 7u and 8 we will be using two different toolsets. But I agree that JPRT and RE should be using the same tools. That needs to be taken up with RE and Kelly.
>>>> 
>>>> Ideally not just using the same tools, but they should _be_ the same systems.  But I digress...
>>> 
>>> 
>>> I have tried very hard to have JPRT match RE, this 6u14 vs. 6u18 difference was a mistake we will correct.
>>> 
>>> However, it is literally impossible to keep any two systems identical all the time,
>> 
>> Exactly.  If the same system is used for checkin-test builds and production builds then you no
>> longer have two systems that need to be 'kept in sync'.  
> 
> I'm missing something. How can everybody using the exact same system scale to 100's of developers?

System = distributed build and test of OpenJDK

Developers send in jobs 
Jobs are distribute across a pool of (HW/OS) resources
The resources may be divided into pools dedicated to different tasks (RE/checkin/perf/stress)
The pools are populated initially according to predictions of load and then increased/rebalanced according to data on actual usage
No assumptions made about what exists on the machine other than HW/OS
The build and test tasks are self sufficient, i.e. bootstrap themselves 
The bootstrapping is done in the same way for different build and test tasks

The only scaling aspect that seems at all challenging is that the current checkin system is designed to serialize checkins in a way that apparently does not scale -- here there are some decisions to be made and tradeoffs but this is nothing new in the world of Open community development (or any large team development for that matter)

> 
> And that one system will naturally change over time too, so unless you are able to prevent all change
> to a system (impossible with security updates etc) every use of that 'same system' will be different.

Yes, but it is possible to control this update and have a staging environment so you know that a HW/OS update will not break the existing successful build when rolled out to the build/test farm.

> 
> -kto
>  
>> 
>> 
>>> and many products used by RE
>>> (like PocketSoft RTPATCH) are simply not available to all JPRT systems.
>>> So this is always a best match situation. I do what I can to match RE because that's a primary goal of JPRT to insure
>>> that RE builds will be successful.
>>> 
>>> We also have little control on when PDIT/GIT system maintenance could change the system
>>> by installing patches or updates on systems. So there is always some randomness to the systems.
>>> 
>>> -kto
>>> 
>>> 
>> 
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/serviceability-dev/attachments/20120129/0cb9beb1/attachment.html