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