<html>
<head>
<meta content="text/html; charset=utf-8" http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<p>Hi Martin,<br>
</p>
<br>
<div class="moz-cite-prefix">On 28/11/2016 20:15, Martin Buchholz
wrote:<br>
</div>
<blockquote
cite="mid:CA+kOe0_7=CmP9WbEGfHM_kNirjf1dzjaTo4Z_Rz0wR0svv+Vxg@mail.gmail.com"
type="cite">
<div dir="ltr"><br>
<div class="gmail_extra"><br>
<div class="gmail_quote">On Fri, Nov 18, 2016 at 8:33 AM, joe
darcy <span dir="ltr"><<a moz-do-not-send="true"
href="mailto:joe.darcy@oracle.com" target="_blank">joe.darcy@oracle.com</a>></span>
wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px
0.8ex;border-left:1px solid
rgb(204,204,204);padding-left:1ex">* A master forest,
serving the roles master and dev play today in 9.<br>
<br>
With a few exceptions, in JDK 9 master was just
time-delayed copy of dev so we can implement recording
the information about which set of sources correspond to
a promoted build without using a whole other forest.<br>
<br>
Rather than using a separate line of development for
client-libs work as in 9, I think this should be done in
the same line of development as all other libs work in 10.<br>
</blockquote>
<div><br>
</div>
<div>For many years, I've been advocating having a
guaranteed always-working, never regressing master and
also always a place for developers to submit-and-forget
their (possibly slightly buggy) changes. All regressions
that could be caught by a test are 100% guaranteed to be
caught by a competent trusted release engineer who is the
only one ever moving changes into the master forest.
Based on this idea, it seems essential to have something
like a jdk10-dev forest (it could also be implemented
using mercurial branches, but that would be a break with
many decades of tradition).</div>
<div><br>
</div>
<div>I notice today the message</div>
<div><a moz-do-not-send="true"
href="http://mail.openjdk.java.net/pipermail/quality-discuss/2016-November/000596.html">http://mail.openjdk.java.net/pipermail/quality-discuss/2016-November/000596.html</a><br>
</div>
<div>where regressions have crept into a jdk9 build, which
is disappointing. The whole point of regression testing
is to ensure that regressions don't happen! And I recall
having that job myself back in 2005!</div>
</div>
</div>
</div>
</blockquote>
We are investigating these failures. <br>
<br>
The reason for posting results, warts and all, is to allow others to
have results to compare with. <br>
The number of failures , in this instance, is unusually high. <br>
<br>
Rgds,Rory <br>
<br>
<br>
<pre class="moz-signature" cols="72">--
Rgds,Rory O'Donnell
Quality Engineering Manager
Oracle EMEA , Dublin, Ireland </pre>
</body>
</html>