A Complicated Slide?

This Dilbert comic strip reminded me of a drawing I did a while back to try and explain the critical nature of our bug tracking system, and how all the various systems we have and use connect back to the bug database. Granted, right now the JDK team is using an internal bug tracking system (that will change someday), and the visibility is limited to what you can see via http://bugs.sun.com/.

The complicated drawing below is mine alone and is not an official JDK drawing and is undoubtedly not 100% correct, it is just my attempt to convey some of the connections to our bug tracking system:

And a few terms to define the words used:

  • Builds Archives: Promoted builds, nightly builds, and the JPRT build archive.
  • Alacrity: A system and set of machines used to run our more critical performance benchmarks in a controlled environment and report on performance results on JDK builds.
  • GTEE: The formal test system that verifies our JDK builds pass all our tests (all our many different kinds of tests).
  • JPRT: My balliwick of late. JPRT is a set of systems and machines (multiple instances of JPRT) that provide build and basic testing on all platforms and both VMs (client & server). JPRT stands for Java Programmer Rat Trap... I'm kidding, I'm not sure what the name stands for anymore. There was an old HotSpot PRT system and that stood for Performance Reliability Testing, and this newer system works with all the JDK repositories, so I named it JPRT. Anyway, it is a system that developers and integrators can submit repositories or source trees for builds on all 8 of our standard platforms (Solaris SPARC, Solaris X86, Windows, and Linux, both 32 and 64 bit). The builds are archived and JPRT can actually update the bugs and push changesets when the job is successful. This is a system we need to somehow make available externally but we don't know exactly how just yet.
  • Testbase: Just represents all the various testbases we have for testing the OpenJDK. Some of these tests are actually in the JDK repositories. These include the JDK TCK (JCK).
  • CR Bug Database: Our internal bug database, some of which is visible via the bugs.sun.com site. The whole point of making this drawing (quite a while back) was to demonstrate how the CR number is used in so many places and the bug tracking system is at the center of everything. Someday, this may be bugzilla for the OpenJDK.
  • CCC: The committee that reviews any change to a user visible API in the JDK. All developers making changes that involving any change to a user visible API or command line option or file format, must file a CCC request and get approval from CCC before pushing their change into a public repository. This is currently an internal process but will be externalized at some point.
  • Integrators: Those blessed souls that deal with the merges between teams and integrate all a teams changes into the master jdk7 repositories.
  • Planning: The planning process will always refer to the CRs as part of the planning process.
  • Source Repositories: The Mercurial repositories or TeamWare workspaces for some of the older releases.
  • WebRevs: An old, extremely valuable, and historic way that Sun Engineers have used to do code reviews. All changes to the JDK are required to be reviewed by at least one other engineer, more than one at critical times of a release. See Jesse's webrev blog on the version of the webrev script we use in the JDK area.

I hope this helps someone and doesn't really confuse people. And no, the rocket ship is not blasting the webrevs. :\^)

-kto

Comments:

Post a Comment:
Comments are closed for this entry.
About

Various blogs on JDK development procedures, including building, build infrastructure, testing, and source maintenance.

Search

Archives
« April 2014
SunMonTueWedThuFriSat
  
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
   
       
Today