Open Development Infrastructure

OpenSolaris Project: Open Development Infrastructure

• Overview
• Overall Goal
• Source Code Management
  • Mercurial and Subversion
  • SCM Console
  • OpenGrok
• Defect Tracking
  • bugs.opensolaris.org (BOO)
  • defect.opensolaris.org
  • Tools/Policies/Processes
• Community Contributions
  • Sponsor Program
  • Small-Bug-Fix-Submission
  • Tools
• Moving Source Repositories

Overview

This project grew out of the SCM Migration Project. Early thoughts were that consolidation gates could be moved onto opensolaris.org as soon as the gates were transitioned to using Mercurial as their source code management (SCM) system. However, it turns out, that there are multiple internal processes and tools tied to the ON gate that makes instant movement not possible. So discussions were held in late October 2008 to figure out how developer collaboration and open development infrastructure could be improved while we work towards moving the ON consolidation gate (and others) to opensolaris.org. This project comes from those discussions.

Overall Goal

The Overall goal of this project is for non-Sun developers to be able to fully participate in the development of code. Work is required in at least the following areas to achieve the Overall goal:

• Source Code Management
• Defect Tracking
• Community Contributions and Associated Processes
• Moving main source repositories to opensolaris.org

Related goals:

• Open-source defect tracking system (see section on defect.opensolaris.org below)

Source Code Management

Projects can currently use Mercurial or Subversion on opensolaris.org. In the short term, most of the work will be related to updates of Mercurial or Subversion, and incremental changes to the tools and hooks (bug fixes, small feature requests). Larger changes may be needed later to provide better support for gates that live on opensolaris.org.  Other work areas related to Source Code Management are the repository management application (aka the SCM Console) and the OpenGrok source browser. See below for more details.

Mercurial and Subversion

Information about Mercurial and transitioning to it from TeamWare can be found in the SCM area of the Tools Community. A pointer to the SCM requirements document and other historical information can be found on the project history page there.

Information about the work involved in transitioning to Mercurial and updating developer tools that work with a variety of source code management (SCM) systems can be found in the SCM Migration Project. Note that ongoing conversation about Mercurial and how to use it occurs on the scm-migration-dev mailing list. Moving forward, Mercurial will be updated to new revisions periodically. Doing upgrades will require coordination between these four areas: 

• Mercurial software in the SFW consolidation
• Cadmium developer tool
• ON gate hooks
• gatekeeper scripts

All four areas will need to coordinate to ensure a clean upgrade: 1) a new version of Mercurial will be obtained; 2) Cadmium will be upgraded to work with the old and new versions; 3) ON gate hooks will be upgraded to work with the old and new versions of Mercurial and Cadmium; 4) the new version of Mercurial will be integrated into OpenSolaris, and the gatekeeper scripts will be updated to work with the new version of Mercurial and Cadmium. Note that the tasks in Step 4 can be separated if the gatekeeper scripts are modified to work with both the old and new versions of
Mercurial and Cadmium. Otherwise, the tasks in Step 4 will need to be carefully coordinated.

Subversion updates should be more straightforward, as we have less custom infrastructure built up around Subversion.

SCM Console

Lead: Martin Walsh  

A re-implemented SCM Console was made available in Nov 2008. It was re-implemented to provide a better platform for future changes. One new feature that is planned is to let project leaders delete repositories in the projects that they lead.  Until this feature is available, project leaders can ask the site operations team (tonic-ops@sun.com) to delete any unwanted repositories. Be sure to give the project name and repository name(s).

OpenGrok

We don't expect much work related to OpenGrok. There may be changes related to new versions from the OpenGrok project. We may also need to help the site operations team and OpenGrok developers deal with issues if they arise (e.g., if new source fails to appear in OpenGrok).

Defect Tracking

bugs.opensolaris.org (BOO)

Lead: Bill Rushmore  

BOO is a bugs-by-mail mechanism that enables non-Sun people to submit bugs to Sun's internal bug database. BOO is not a bridge to the internal database. Bugs can be submitted, external users can add themselves to the Interest List of a bug, and bugs in categories/subcategories available via BOO can be queried and viewed. Existing bugs can not be updated. 

The basic plan for BOO is simple: 

• The bugs.opensolaris.org application was deployed on opensolaris.org servers in May 2009. (The application was previously owned and run elsewhere within Sun.)
• Work on a list of enhancements is on hold pending general decisions about bug tracking.  Note: Bugs logged against BOO are currently mostly in Bugster.  Need to decide whether to move them to defect.opensolaris.org and how to publish the list and information about progress.

defect.opensolaris.org

Lead: Bill Rushmore  

Open defect tracking has been a goal of the OpenSolaris project since the initial launch in 2005. Requirements for an open defect tracking system were formulated in 2007 and captured in the requirements document. 

Four candidates were evaluated: RoundUp, Mantis BT, Eventum and Bugzilla. Bugzilla was chosen December 2007, as explained in the selection document.  

defect.opensolaris.org is an instance of Bugzilla running in a zone on an opensolaris.org server. The current instance of bugzilla is not tied to the opensolaris.org membership database. It is on the list to integrate defect.opensolaris.org with the Auth database.  When that happens, administration of the use of defect.opensolaris.org will remain with the 'administrators' currently on the tools-discuss mailing list.

Tools/Policies/Processes

The use of two defect tracking systems is currently confusing because we do not yet have definitions of appropriate use, tools to support the managed migration between systems or unified search capabilities. Work has started to lay out an information architecture so that development tools can be defect-tracking system agnostic.

Community Contributions

Sponsor Program

The OpenSolaris Sponsor Program was started when the site originally launched as a way to enable external code contributions to gates that were inside Sun's firewall. It was intended to be a temporary solution until gates moved outside onto opensolaris.org. As gate movement will take longer than originally anticipated, this program will be in place much longer than originally anticipated. The target is that requests for a sponsor be picked up within a week of being posted.

The request-sponsor table contains all the requests and status information.

Small-Bug-Fix-Submission

Project  Lead: Mark Nelson  

One idea for improving the sponsor program is to set up an ON engineering project on opensolaris.org

This project would take small bug fixes and periodically, it would integrate into the ON gate. External contributors could work directly on the project. Enabling direct participation means that Sun engineers do not have to do significant work for very simple fixes, and it enables external contributors to participate directly, handling code reviews, testing, etc. by themselves.

In addition, this project will give us a space in which new tools, changes to existing tools, and the processes around using them can be tested on a small audience. For example, the expectation is that the work to make tools agnostic with regard to defect tracking, an OpenRTI tool of some kind, and other ideas would be implemented and used here first and then evolved as we learn.

To enable this project, the following is needed:

• Definition of exactly what kinds of bugs qualify for this project;
• OpenRTI tool so external contributors can submit their own RTIs,
• Decision about whether bugs must all be logged in defect.opensolaris.org or whether Bugster bugs can be cited;
• Project processes defined and published;
• What else?

Tools

New tools and changes to existing tools are also needed to make contributions easier. Some tools will be updated as noted above to be agnostic about defect tracking systems. New tools, like OpenRTI, will be created to support an integration approval process. We may also investigate process changes, such as supporting a pull
model for consolidations like ON. A list and detail about each item on the list is the next step.

Moving Source Repositories

The main source repository for a Solaris/OpenSolaris consolidation is referred to as a gate. The final step in achieving full open development is having all the source gates on opensolaris.org. But this step is the final step. The tools and processes noted above are needed in order to support the use of the gates once they are on opensolaris.org. Detail about this area will be worked out as we get closer to its implementation.