The publication last week of our experimental Mercurial repositories heralds the first of many infrastructure projects that we hope to initiate, and in most cases complete, over the next year or so. Here’s the entire list:

2007/Q4	Code-review publication Core community database Public Mercurial forests
2008/Q1	Mercurial forest management OpenGrok
2008/Q2	Improved content publishing Process tools
2008/Q?	Bug database Distributed build system

All dates are—naturally—somewhat approximate. In more detail:

Code-review publication A simple way to publish webrevs for all to see. Should accommodate the code review robot and similar internal (for now) automated tools. Should also collect diffs and send them in e-mail, for those who prefer that format. This project will help move more Sun engineering conversations into the open. (I’ve previously blogged about this, and there was some good feedback on the discuss list.) — 2007/Q4

Core community database Tracks Members, Groups, Projects, Mercurial repositories, and the relationships between them. Holds personal information including full name, e-mail address, ssh keys, etc. The first version need only support a command-line interface; a full web interface can follow later. Required for Mercurial. — 2007/Q4

Public Mercurial forests Master repository forests as well as group integration forests for JDK 7, and then JDK 6. Forest management need not be fully automated at first; i.e., it’s okay to require manual steps on the Mercurial servers to create and configure forests, though those steps should be scripted insofar as possible. — 2007/Q4

Mercurial forest management Enable Moderators of any Project to create and manage Project-specific repositories and/or forests, and to grant push rights to contributors. Manual steps on the Mercurial servers should never (well, hardly ever) be required. — 2008/Q1

OpenGrok Install and configure OpenGrok for the JDK 7 and 6 forests; support others later on. — 2008/Q1

Improved content publishing Something beyond today’s interim mechanism, in which a Mercurial repository full of HTML files is transformed by an XSLT stylesheet and then pushed to the web servers. A full wiki is probably overkill, but it should be possible to edit content both locally as well as in a web browser, for those who prefer that mode. Should support dynamic page content. — 2008/Q2

Process tools External versions of the internal feature-planning, interface-review, change-approval, and other workflow tools that the Sun JDK team currently uses to manage work on the various JDK code bases. — 2008/Q2

Bug database An open bug database usable by all contributors, not just Sun employees as is the situation today. Our basic requirements are pretty much the same as those identified by the OpenSolaris Community, so naturally we’ve been following their evaluation process with interest. In their most recent discussions (see here, and here) they seem to be leaning pretty strongly toward Bugzilla. — 2008/Q?

Distributed build system A Tinderbox-like service that builds OpenJDK forests on demand, or nightly, and publishes the results. Should allow for builds to take place on non-Sun machines for ports that Sun does not maintain. Target the JDK 7/6 masters to start, then expand to group forests, then to arbitrary developer forests. We already have an internal system which does much of this and so might be a good starting point—see Kelly’s blog on JPRT for an overview. — 2008/Q?

That’s it If we’ve missed anything then please do let us know, either in comments below or on the discuss(at)openjdk.java.net list. (If you haven’t already subscribed to that list then please do so before posting, otherwise your message will be discarded as spam.)