<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Nov 28, 2016 at 4:50 PM, Joseph D. 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:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
  
    
  
  <div bgcolor="#FFFFFF" text="#000000"><span class="">
    On 11/28/2016 3:30 PM, Martin Buchholz wrote:</span><span class=""> <blockquote type="cite"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">
            <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
              As an aside, for JDK 10 I'd also like to see promoted
              builds on a more frequent schedule than once a week.<span><br>
              </span></blockquote>
            <div><br>
            </div>
            <div>People do "continuous testing and integration" these
              days.  Set up your integration pipeline so that it is
              always running.  The pipeline automatically promotes
              changesets to master when all tests pass.  Easy!  Then
              every master changeset is equally stable to a "promoted
              build".</div>
          </div>
        </div>
      </div>
    </blockquote>
    <br></span>
    One of the internal systems mentioned above is a CI system that run
    regression tests after a change is pushed. The approximate
    integration model is then to promote known-good states of sources as
    vetted by the CI system.<br>
    <br>
    If problems are fixed soon after they are identified, then a
    post-push system gives good results with avoiding the need more
    complexity on the front end to manage a series of in-flight patches.<br></div></blockquote><div><br></div><div>A CI system available to every committer that would guarantee no regressions would be awesome!</div><div><br></div><div>I fundamentally do not believe in post-submit testing. I want to be protected from my own mistakes and those of others.  Google has also moved towards doing more presubmit testing. </div><div><br></div><div>For large low-level infrastructure projects like openjdk, I envision different layers of testing.  The first layer would run e.g. the jtreg and jck tests, perhaps on a distributed test farm.  A second layer might run publicly available java test suites that would be too expensive to run in a first layer.  Promotion to a "golden master" might be dependent on passing tests in the second layer.  Of course, that would be a serious investment in testing/quality.</div></div></div></div>