<html><head></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><br><div><div>On 28 jan 2012, at 09:46, Kelly O'Hair wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><br><div><div>On Jan 27, 2012, at 9:52 PM, Georges Saab wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><br><div><div>On 27 jan 2012, at 12:40, Kelly O'Hair wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><br><div><div>On Jan 26, 2012, at 2:47 PM, Georges Saab wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><span class="Apple-style-span" style="border-collapse: separate; font-family: Times; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: 2; text-align: -webkit-auto; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; -webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing: 0px; -webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px; font-size: medium; "><div><blockquote type="cite">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.<br></blockquote><br>Ideally not just using the same tools, but they should _be_ the same systems. But I digress...<br></div></span></blockquote></div><div><br></div><div>I have tried very hard to have JPRT match RE, this 6u14 vs. 6u18 difference was a mistake we will correct.</div><div><br></div><div>However, it is literally impossible to keep any two systems identical all the time, </div></div></blockquote><div><br></div><div>Exactly. If the same system is used for checkin-test builds and production builds then you no</div><div>longer have two systems that need to be 'kept in sync'. </div></div></div></blockquote><div><br></div>I'm missing something. How can everybody using the exact same system scale to 100's of developers?</div></div></blockquote><div><br></div><div>System = distributed build and test of OpenJDK</div><div><br></div><div>Developers send in jobs </div><div>Jobs are distribute across a pool of (HW/OS) resources</div><div>The resources may be divided into pools dedicated to different tasks (RE/checkin/perf/stress)</div><div>The pools are populated initially according to predictions of load and then increased/rebalanced according to data on actual usage</div><div>No assumptions made about what exists on the machine other than HW/OS</div><div>The build and test tasks are self sufficient, i.e. bootstrap themselves </div><div>The bootstrapping is done in the same way for different build and test tasks</div><div><br></div><div>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)</div><br><blockquote type="cite"><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><div><br></div><div>And that one system will naturally change over time too, so unless you are able to prevent all change</div><div>to a system (impossible with security updates etc) every use of that 'same system' will be different.</div></div></blockquote><div><br></div><div>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.</div><br><blockquote type="cite"><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><div><br></div><div>-kto</div><div> </div><div><blockquote type="cite"><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><div><div><br></div><div><br></div><blockquote type="cite"><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><div>and many products used by RE</div><div>(like PocketSoft RTPATCH) are simply not available to all JPRT systems.</div><div>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</div><div>that RE builds will be successful.</div><div><br></div><div>We also have little control on when PDIT/GIT system maintenance could change the system</div><div>by installing patches or updates on systems. So there is always some randomness to the systems.</div><div><br></div><div>-kto</div><div><br></div><br></div></blockquote></div><br></div></blockquote></div><br></div></blockquote></div><br></body></html>