<html><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><br><div><div>On Feb 21, 2011, at 1:33 PM, Dr Andrew John Hughes wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><div>On 18:29 Fri 18 Feb , Kelly O'Hair wrote:<br><blockquote type="cite"><br></blockquote><blockquote type="cite">On Feb 18, 2011, at 4:29 PM, Dr Andrew John Hughes wrote:<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite"><blockquote type="cite">On 14:09 Fri 18 Feb , Kelly O'Hair wrote:<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><snip><br></blockquote></blockquote></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">But there have been some roadblocks for the open source community.<br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">It has been observed (for a long time now) that:<br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"> * The Mercurial jcheck extension needs to be open sourced<br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">Funnily enough, I just mentioned that in my reply to your mail about <br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">the jdk6 changesets... :-)<br></blockquote></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">Hopefully we will hear some good news on this soon.<br></blockquote><blockquote type="cite"><br></blockquote><br>That'd be good.<br><br><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"> * The bug tracking system needs to be completely open<br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">Definitely. Making OpenJDK bug DB IDs usable in changesets would be <br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">a good start (probably involves jcheck...)<br></blockquote></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">I'll have to punt on that, someone else is working on it, but the <br></blockquote><blockquote type="cite">intent is to have a<br></blockquote><blockquote type="cite">completely open bug tracking system that also allows us link it with <br></blockquote><blockquote type="cite">the internal Oracle<br></blockquote><blockquote type="cite">bug tracking system. Once we have that defined, jcheck can be adjusted <br></blockquote><blockquote type="cite">to use those numbers<br></blockquote><blockquote type="cite">or IDs. I don't think all the details are worked out. I'll see if I <br></blockquote><blockquote type="cite">can ping someone to make<br></blockquote><blockquote type="cite">some of the planning more public.<br></blockquote><blockquote type="cite"><br></blockquote><br>So this is going to be yet another system? What will happen to the existing<br>pretty much unused OpenJDK bug database?<br></div></blockquote><div><br></div>It's not clear. The old Sun bugtraq system was closed but we had some ability to expose information.</div><div>The Oracle bug system is very closed, so the requirements have changed with regards to how the open and</div><div>closed interact together.</div><div>Before we mostly worked with Sun bugtraq, some public exposure, and slightly augmented by the openjdk bugzilla.</div><div>(and we did a poor job of watching over the bugzilla system, sorry).</div><div>In the future it may be more that everyone is using the open system (whatever that is), and only augmented</div><div>by the closed system when needed. Bottom line is that this is a good thing for the open side,</div><div>but I have no idea what that open system will be at this time. It's a plan for a plan, and in progress.</div><div>I think when this gets rolled out, other than perhaps people not liking the particular implementation that</div><div>might get picked, the open world will be better off because it will be THE default bug tracking system.</div><div><br></div><div><div>Of course I have to clarify,</div><div><b><i> The views expressed in this email are my own and do not necessarily reflect the views of Oracle.</i></b></div><div><b><i><br></i></b></div><b><i></i></b><b><i></i></b></div><div><br></div><div><blockquote type="cite"><div><br><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"> * We need an open build and test system for the OpenJDK developers<br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">who don't have access to all the systems<br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">This is especially important for Windows as I have no idea if <br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">anything I do breaks it and<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">no way of doing builds on it. I expect the same to be true when Mac <br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">OS appears as a target.<br></blockquote></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">Yup. The number of platforms is going up, which makes it even more <br></blockquote><blockquote type="cite">important.<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><snip><br></blockquote></blockquote></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">How much can be opened?<br></blockquote></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">Currently the parts that can't be opened that I can think of off the <br></blockquote><blockquote type="cite">top of my head:<br></blockquote><blockquote type="cite"> * Closed builds or builds that include both the open changes and <br></blockquote><blockquote type="cite">the private Oracle repositories for JDK7<br></blockquote><blockquote type="cite"> * Certain VM tests that are publicly available, like SPEC benchmarks<br></blockquote><blockquote type="cite"> * Certain VM tests that are Oracle private, but have been <br></blockquote><blockquote type="cite">historically run to verify VM stability<br></blockquote><blockquote type="cite"> * Some closed jdk regression tests, security and otherwise<br></blockquote><blockquote type="cite"><br></blockquote><br>The first two mainly sound like things that matter to Oracle. Breaking<br>Oracle's proprietary product is not ideal, but something only really Oracle<br>can deal with and not the rest of the community. I presume the SPEC benchmarks<br>would catch performance degradations; this would be useful, but not too helpful<br>if you can't make the results public. I don't see how either could ever be made<br>public so I think it's best to keep them separate from the open system.<br></div></blockquote><div><br></div>Actually, these SPEC benchmarks are mostly used to verify correctness in the builds.</div><div>They do a good job of self checking their results, and triggering lots of VM actions</div><div>to happen when they run, so they actually serve as good stability tests.</div><div>Kind of like stress tests.</div><div><br><blockquote type="cite"><div><br>The latter two also need to be kept separate to begin with, but I hope Oracle<br>will be able to make these open at some point in the future.<br></div></blockquote><div><br></div>I can't promise anything like that, but I suspect if a particular testcase or testsuite becomes</div><div>a good bug finder, some developer may decide to try and open it up just to make life easier</div><div>for everyone. Probably a case by case situation.</div><div><br><blockquote type="cite"><div><br><blockquote type="cite">The general feeling is that we would not allow people to login to <br></blockquote><blockquote type="cite">these systems, but we<br></blockquote><blockquote type="cite">could provide complete specifications on what systems we are using.<br></blockquote><blockquote type="cite">Providing systems for OpenJDK people to access is not something we are <br></blockquote><blockquote type="cite">thinking about.<br></blockquote><blockquote type="cite">Internally, it's rare that the exact same systems used like this are <br></blockquote><blockquote type="cite">needed by the developer.<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">My preference is that other than the above items, any developer should <br></blockquote><blockquote type="cite">be able to build<br></blockquote><blockquote type="cite">and test themselves on their platform, via the Makefiles in the <br></blockquote><blockquote type="cite">repositories, e.g. make all test.<br></blockquote><blockquote type="cite">And for the most part, the BAT system would just repeat the same <br></blockquote><blockquote type="cite">procedures the developer<br></blockquote><blockquote type="cite">can do on many other systems and in a distributed fashion for fast <br></blockquote><blockquote type="cite">turnaround.<br></blockquote><blockquote type="cite"><br></blockquote><br>Will any OpenJDK developer be able to submit a job to this system? If not,<br>then it again creates a reliance on Oracle developers as we already have<br>with the Oracle bug DB and the JPRT system.<br></div></blockquote><div><br></div>The idea is that any OpenJDK developer with commit rights could submit to the system.</div><div><br></div><div>Ultimately we want to allow for anybody to:</div><div> * File/edit/change a bug in a bug tracking system</div><div> * Get reviews from any OpenJDK user with commit rights</div><div> * Use the jcheck extension to verify changesets prior to push or submit into a build&test system</div><div> * Submit proposed or final changes to a build&test system</div><div><br></div><div>No required Oracle assistance, other than getting commit rights and informal approval</div><div>from the team that owns the destination repositories.</div><div><div><b><i><br></i></b></div><b><i></i></b><b><i></i></b></div><div><br><blockquote type="cite"><div><br><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">From my stand point, I'd much rather we had the system completely open<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">with those tests that can be made so, with appropriate direction in<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">how to improve things and "fill in the holes". A bit like OpenJDK and<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">the 'plugs'. Improving that is achievable, and expanding the range of<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">open tests would be some good low-hanging fruit for the OpenJDK<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">project. It would also establish a good set of JDK tests that can be<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">used elsewhere. This is what we tried to do with Mauve<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">(<a href="http://sourceware.org/mauve/">http://sourceware.org/mauve/</a>).<br></blockquote></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">I would like to include mauve tests as part of the testing, if we can <br></blockquote><blockquote type="cite">fit it in.<br></blockquote><br>That's be great.<br><br><blockquote type="cite">I agree open tests are preferred.<br></blockquote><blockquote type="cite"><br></blockquote><br>As I say, I don't see much point in anything else. What use are tests<br>we can't discuss? How can we even trust their results?<br></div></blockquote><div><br></div><div>I think if any of these tests become issues, we can address it then.</div><div>Like I said, it may be this event that triggers the discussion on what we should be doing</div><div>in terms of opening up a test, or not requiring a test be run.</div><br><blockquote type="cite"><div><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">Working with proprietary tests doesn't really help. It doesn't tell <br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">me<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">anything if a test passes if I don't know what that test is; I don't <br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">know<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">what exactly is being tested and whether I should trust the test at <br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">all.<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">I already have some experience of working with such tests via the TCK<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">and it's been much more of a hinderance than a help, especially when<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">we can't openly discuss tests and their results. If I can't get a<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">commit into OpenJDK because some test I can't look at is failing,<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">it's just going to make me not want to bother trying.<br></blockquote></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">I understand the frustrations with TCK. But TCK is generally not what <br></blockquote><blockquote type="cite">we need<br></blockquote><blockquote type="cite">at the developer stage. I'd be more interested in running mauve than <br></blockquote><blockquote type="cite">TCK.<br></blockquote><blockquote type="cite">TCK is something that might get run at Integration time in my opinion.<br></blockquote><blockquote type="cite"><br></blockquote><br>I wasn't suggesting we run the TCK; far from it. I was merely using it<br>as an example of how NOT to setup this system :-)<br></div></blockquote><div><br></div>Ah. Gotcha. </div><div><br><blockquote type="cite"><div><br><blockquote type="cite">The primary tests we would run to start with the jdk repository would <br></blockquote><blockquote type="cite">be the regression<br></blockquote><blockquote type="cite">tests in the repository, at least that's what I was thinking. Adding <br></blockquote><blockquote type="cite">in mauve might be next?<br></blockquote><blockquote type="cite">The VM tests used are the trickier ones.<br></blockquote><blockquote type="cite"><br></blockquote><br>That sounds good. Merely doing builds, never mind tests, on platforms<br>such as Windows, Solaris and Mac OS X will be an advantage.<br><br></div></blockquote><div><br></div>To be completely upfront, there is a catch, it's not clear to me whether the actual built bits can</div><div>be returned yet, in amm os-arch cases. That's a legal issue I need to resolve.</div><div>I don't have a problem with it, but I need to make sure it's ok. So initially, all you might get back</div><div>are the build logs and a success/failure indication, I'll work on the getting the built bits back,</div><div>but no promises.</div><div><br><blockquote type="cite"><div>Will OpenJDK6 also be covered by this scheme? At the moment, results<br>for it are of greater value for most people than those for the<br>unreleased OpenJDK7.<br></div></blockquote><div><br></div>I'll allow for OpenJDK6, but we may need to play with what the configurations are</div><div>for building and testing, e.g. the os-arch-compiler combinations to build and test.</div><div><br></div><div><br></div><div><div>Of course I have to clarify, again ;^)</div><div><b><i> The views expressed in this email are my own and do not necessarily reflect the views of Oracle.</i></b></div><div><b><i><br></i></b></div></div><div>-kto</div><div><br><blockquote type="cite"><div><br><blockquote type="cite">-kto<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">-kto<br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">-- <br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">Andrew :)<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">Free Java Software Engineer<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">Red Hat, Inc. (<a href="http://www.redhat.com">http://www.redhat.com</a>)<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">Support Free Java!<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">Contribute to GNU Classpath and IcedTea<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><a href="http://www.gnu.org/software/classpath">http://www.gnu.org/software/classpath</a><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><a href="http://icedtea.classpath.org">http://icedtea.classpath.org</a><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">PGP Key: F5862A37 (<a href="https://keys.indymedia.org/">https://keys.indymedia.org/</a>)<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">Fingerprint = EA30 D855 D50F 90CD F54D 0698 0713 C3ED F586 2A37<br></blockquote></blockquote><blockquote type="cite"><br></blockquote><br></div></blockquote><div><br></div><div><br></div><div><div>Of course I have to clarify,</div><div><b><i> The views expressed in this email are my own and do not necessarily reflect the views of Oracle.</i></b></div><div><b><i><br></i></b></div><div><b><i>:^)</i></b></div><div><b><i><br></i></b></div></div>-kto</div><div><br><blockquote type="cite"><div>-- <br>Andrew :)<br><br>Free Java Software Engineer<br>Red Hat, Inc. (<a href="http://www.redhat.com">http://www.redhat.com</a>)<br><br>Support Free Java!<br>Contribute to GNU Classpath and IcedTea<br><a href="http://www.gnu.org/software/classpath">http://www.gnu.org/software/classpath</a><br>http://icedtea.classpath.org<br>PGP Key: F5862A37 (https://keys.indymedia.org/)<br>Fingerprint = EA30 D855 D50F 90CD F54D 0698 0713 C3ED F586 2A37<br></div></blockquote></div><br></body></html>