Skip to main content

OpenJDK Mercurial Transition Update 1

Posted by kellyohair on August 21, 2007 at 6:00 PM PDT


The work to create OpenJDK/JDK7 Mercurial repositories is progressing,
but before I tell you anything significant, I'll bore you
with some basic details about JDK building. ;^)

JDK Build Promotions

    First, let me explain a little about the JDK build promotions.
    The build promotion cycle for active releases
    is usually 1 or 2 weeks long, and currently
    for JDK7 it's 2 weeks. That means that roughly every 2 weeks, a
    promoted JDK7 build is made available at the
    jdk7.dev.java.net
    binary bundle area (plus the JRL source bundle area), and also at the
    OpenJDK.java.net
    source bundle area. I assume people see the emails sent out on
    promotions to
    the announce@openjdk.java.net alias (subscribe at the
    openjdk mailing lists
    site).

    Between promotions,
    individuals integrate their JDK7 changes
    into the various team integration areas, and
    the teams will then integrate their changes into the
    MASTER JDK7 source workspaces.
    The MASTER source workspaces are like the Pacific Ocean,
    with all the various teams sending
    their changes to the MASTER repositories like water flowing through
    the various rivers, lakes, etc. into the Pacific.
    At any point the changes might get held up or inspected by
    a "gate keeper" or "integrator", like the dam operators on rivers
    (that's "dam operators", not "damn operators").
    Ok ok, strange analogy, but it kind of fits.
    In any case, sometimes a change looks like it might
    make it into the MASTER workspaces and into a build promotion,
    but it doesn't, some gate keeper might
    scoop it out of the river, or some bear might drink it or something
    (some bears might also make contribution to the river,
    but let's not go there, most of the pesky bears have been relocated
    north of here).
    Ultimately if a change doesn't make a promotion and isn't permanently
    diverted, it will make the next promotion, or the one after that,
    just depends on how far it has to go.
    (And yes, testing is part of this process, the water is
    indeed safe to drink).

    The schedule for when build promotions will happen is fairly
    predictable, but anything can happen, and sometimes they get
    delayed. The current schedule is... HA, you thought I was
    going to give you hard dates!
    ... well ok, why not, but
    these are estimated dates, and sometimes you need to add a day
    to the final promotion day
    before the actual bundles are available on the
    jdk7.dev.java.net and openjdk.java.net sites:

    • JDK7 Build 19 final - estimated Aug 31
    • JDK7 Build 20 final - estimated Sept 14
    • JDK7 Build 21 final - estimated Sept 28
    • JDK7 Build 22 final - estimated Oct 12
    • JDK7 Build 23 final - estimated Oct 26

    If a build slips, all the following build promotion
    dates have to be permanently adjusted.
    These build promotion
    dates are probably no big surprise, anyone could
    look at the past delivery of JDK7 build promotions and guessed
    this much. But I wanted to attach at least some preliminary dates
    to some build numbers so you understand the planning a bit.

    Note that once we get into delivering Mercurial repositories,
    the whole "time frame" as to when you see source changes
    is drastically different.
    The traditional
    source bundles become less interesting, except for maybe archiving.
    And even after Mercurial,
    the JDK Build Promotions will continue, and the binary bundles
    and all deliveries to jdk7.dev.java.net won't change much.

The "langtools" Separation

    Second, hopefully in Build 19 (backup plan is Build 20)
    we will be doing
    some major restructuring of the j2se workspace.
    This first restructuring is called the "langtools" separation.
    The "langtools" are the tools javac, javah, javap, javadoc, and apt.
    This change is significant because it removes the fairly
    complicated javac "recompile" cycle from the j2se build, and
    greatly simplifies the j2se build (many Makefiles get deleted).
    It introduces another tree of sources (about 3,000 files)
    with the name "langtools".

    No, it doesn't mean the entire j2se build can convert to ant.

Other Changes

    Third, in Builds 20 through 22 or 22, there may be additional
    restructurings and things like SCCS keyword removals.

The Transition

    Lastly, we sincerely hope that Build 22 or 23 will be the last
    promotion built with TeamWare sources, meaning that at some point
    after those promotions we can start working on making the
    OpenJDK repositories available, probably fairly quickly in terms
    of a read-only state.

Mercurial Transition Details

    Just to make sure people are aware of some of the technical details of
    how the transformation will happen:

    • A Set of Repositories

      Keep in mind that we are talking about a set of repositories, not
      just one.
      The current repository set is: control, langtools, j2se, and hotspot.
      A one-to-one mapping from the TeamWare workspaces to the
      Mercurial repositories will be maintained at transition time.
      (Although we had plans for a Mercurial forest, and may use them
      eventually, for now the OpenJDK repositories will likely
      just be a set of separate repositories).

      And more important, we are probably talking many different sets
      of repositories, one set for the MASTER repositories which
      are read-only to everyone except the gate keepers or integrators,
      plus potentially a set of repositories for each of the
      team integration areas. The specific details remains to be seen.
      With a

      DSCM

      system like Mercurial or TeamWare, you usually end up with the
      Ocean and rivers analogy I mentioned above, with changes trickling
      in over time, from various team integration areas.
      Just looking at the MASTER level may be appropriate for some,
      but for others, particular team integration areas may be of more
      interest. The patterns we have used over the years with TeamWare
      will map pretty much the same way to Mercurial.

    • History of Past Changes

      No past history of the sources will be included (for legal reasons we can't provide history prior to the launch, and for technical reasons
      we decided to not provide the TeamWare history between the launch and
      the transition).
      Effectively each file will be 'sccs edit'd out of the TeamWare
      workspace, and added to a Mercurial repository.

Conclusion

Hope this was helpful.
This project has been extremely hard to predict, and I'm still not
sure that some evil issue won't de-rail the plans, but hopefully
this keeps you all informed.

It will be over soon, I hope, as you can tell from my writing
I'm getting a little dingy (no I'm not getting a small boat). ;^)

-kto


Related Topics >>