<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
  <head>
    <meta content="text/html; charset=ISO-8859-1"
      http-equiv="Content-Type">
    <title></title>
  </head>
  <body text="#000000" bgcolor="#ffffff">
    On 11/03/11 17:06, Kelly O'Hair wrote:
    <blockquote
      cite="mid:174F1AE0-C5CB-44A1-BCF5-54DFDB95D191@oracle.com"
      type="cite"><br>
      <div>
        <div>On Mar 11, 2011, at 2:04 AM, Steve Poole wrote:</div>
        <br class="Apple-interchange-newline">
        <blockquote type="cite">
          <div text="#000000" bgcolor="#ffffff"> On 11/03/11 01:14,
            David Holmes wrote:
            <blockquote cite="mid:4D797790.9010908@oracle.com"
              type="cite">Dr Andrew John Hughes said the following on
              03/11/11 10:57: <br>
              <blockquote type="cite">On 06:40 Fri 11 Mar     , David
                Holmes wrote: <br>
                <blockquote type="cite">Stepping up a level, an initial
                  download of openjdk need not involve <br>
                  using mercurial at all. You can simply download a
                  stable snapshot as a <br>
                  tar file; </blockquote>
                <br>
                This makes much more sense as a starting point for new
                users over having <br>
                to handle Mercurial and checkouts.  It works fine if you
                just want to _use_ <br>
                the latest and greatest, not hack on it. <br>
              </blockquote>
              <br>
              Even if you want to hack you can still do your initial
              download this way. The hg commands only come into play
              when you want to update things later. <br>
            </blockquote>
            <br>
            That's the main point for me -  I want to get easy updates
            -  checking out code from a repo is much nicer than having
            to download a tar and apply your changes.   Mercurials
            update and merge capabilities are great.    <br>
            <br>
            BTW - its important that whatever process is documented is
            one that's used by developers.  So though it may be tempting
            to have complete snapshots of a build tree available - 
            unless someone actively proves they work, its best to have a
            singular process that <b>everyone</b> uses everyday.  <br>
            <br>
          </div>
        </blockquote>
        <div><br>
        </div>
        A singular process that everyone uses?  Good Luck with that. I
        think that is called "herding cats". :^)</div>
      <div>Sorry, I've been doing this too long, if there is a variation
        on doing development and one person finds</div>
      <div>it productive for them, they will use it.</div>
      <div><br>
      </div>
    </blockquote>
    Sorry  - I was not being clear.    I meant that you must have one
    singular process that is the agreed "official" process.   If someone
    decides to do something different that's ok -  provided they
    understand that they have to take their lumps when and if they cause
    a break in the main build or cause testcases to fail.     The
    important point I was trying to make is that the process used by
    contributors must always work.  In my opinion the best way to
    achieve that is to ensure it's in use day by day.<br>
    <br>
    <blockquote
      cite="mid:174F1AE0-C5CB-44A1-BCF5-54DFDB95D191@oracle.com"
      type="cite">
      <div>The complete OpenJDK source bundles are simply a forest with
        the .hg directories removed, and they have</div>
      <div>only been provided for the community because they were asked
        for. They are the same sources that are tagged</div>
      <div>as a promoted build, nothing special.</div>
      <div>I don't know any 'developers' that are using them, they use
        Mercurial/hg.</div>
      <div><br>
      </div>
      <div>Tools like Mercurial/Git allow for multiple clones and
        separate development by different teams, so getting "updates"
        depends</div>
      <div>on where in the layers you want to get your "updates".</div>
      <div>The master forest from <a moz-do-not-send="true"
          href="http://hg.openjdk.java.net/jdk7/jdk7">http://hg.openjdk.java.net/jdk7/jdk7</a>
        is updated maybe twice a day, usually promoted</div>
      <div>and tagged once a week. Only the tagged 'promoted' sources
        that were used to create our promoted jdk7 builds,</div>
      <div>can be guaranteed to be major disease (regression) free. See
        the builds and integrations page at</div>
      <div><a moz-do-not-send="true"
          href="http://openjdk.java.net/projects/jdk7/builds/">http://openjdk.java.net/projects/jdk7/builds/</a></div>
      <div><br>
      </div>
      <div>So the safest changes are probably available by doing a pull
        (or fpull) with "--rev jdk7-bNNN", where NNN is</div>
      <div>currently 132 I think.</div>
      <div><br>
      </div>
      <div>Humm... maybe the RE team needs to create a jdk7-latest or
        jdk7-ea tag at each promotion?</div>
      <div><br>
      </div>
      <div>-kto</div>
      <div><br>
        <blockquote type="cite">
          <div text="#000000" bgcolor="#ffffff"> Checking out using hg
            is simple - the only wart is the forest extension and that's
            only because its unclear what the community view is on using
            it.  <br>
            <blockquote cite="mid:4D797790.9010908@oracle.com"
              type="cite"> <br>
              <blockquote type="cite">
                <blockquote type="cite">or download an install script
                  that will do whatever is <br>
                  necessary behind the scenes to get a complete openjdk.
                  <br>
                </blockquote>
                <br>
                I don't know how that would work.  I guess IcedTea comes
                close to this idea <br>
                in that it detects the needed settings for the build,
                rather than them all <br>
                having to be passed as make variables. <br>
              </blockquote>
              <br>
              I was thinking of a simple installer as used by various
              bits of software. For example for Linux you might download
              a script that simply contains the initial set of hg
              commands needed to get the forest. On windows it might
              automate downloading a tarball and extracting it. <br>
              <br>
              <blockquote type="cite">
                <blockquote type="cite">Personally I'd <br>
                  like to see that include the basic build tools as well
                  - in which case I <br>
                  don't care about "special extensions" as I just get a
                  working toolkit. </blockquote>
                <br>
                What do you mean by this?  Can you give an example? <br>
              </blockquote>
              <br>
              I know this is not what most people want and not how most
              OS handle software packaging these days, but I think it
              would be useful to be able to grab a tools bundles for a
              given OS that includes the various tools and extras you
              need eg mercurial, ant, gcc, freetype - all the things the
              build docs tell you that you have to go and get to build
              openjdk. Just yesterday I had to go and grab freetype and
              get it installed on a machine; today I've had to install
              gawk and libasound2-dev. I find this a PITA. <br>
              <br>
              I don't expect to see this happen, my point was that if
              you did have easy access to pre-packaged tools, then it
              wouldn't matter if openjdk required customized variants of
              those tools. <br>
              <br>
              David <br>
            </blockquote>
            <br>
          </div>
        </blockquote>
      </div>
      <br>
    </blockquote>
    <br>
  </body>
</html>