Wiki code for Open Development Infrastructure

Hide Line numbers
1: = OpenSolaris Project: Open Development Infrastructure =
2: 
3: {{toc start="2" depth="3" numbered="false" scope="page"/}}
4: 
5: == Overview ==
6: 
7: 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.
8: 
9: == Overall Goal ==
10: 
11: 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:
12: 
13: * Source Code Management
14: * Defect Tracking
15: * Community Contributions and Associated Processes
16: * Moving main source repositories to opensolaris.org
17: 
18: Related goals:
19: 
20: * Open-source defect tracking system (see section on [[defect.opensolaris.org>>#doo]] below)
21: 
22: == Source Code Management ==
23: 
24: 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.
25: 
26: === Mercurial and Subversion ===
27: 
28: Information about Mercurial and transitioning to it from TeamWare can be found in the [[SCM area>>Community Group tools.scm]] of the Tools Community. A pointer to the SCM requirements document and other historical information can be found on the [[project history>>Community Group tools.history]] page there.
29: 
30: 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>>Project scm-migration.WebHome]]. 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: 
31: 
32: * Mercurial software in the SFW consolidation
33: * Cadmium developer tool
34: * ON gate hooks
35: * gatekeeper scripts
36: 
37: 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
38: Mercurial and Cadmium. Otherwise, the tasks in Step 4 will need to be carefully coordinated.
39: 
40: Subversion updates should be more straightforward, as we have less custom infrastructure built up around Subversion.
41: 
42: |=SCM System |=Version |=Nevada Build |=Date
43: |Mercurial|1.3.1|Build 123|August 2009
44: |Mercurial|1.1.2|Build 111|March 2009
45: |Subversion|1.4.3| | April 2007
46: 
47: === SCM Console ===
48: 
49: Lead: Martin Walsh  
50: 
51: 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).
52: 
53: === OpenGrok ===
54: 
55: We don’t expect much work related to OpenGrok. There may be changes related to new versions from the [[OpenGrok project>>Project opengrok.WebHome]]. 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).
56: 
57: == Defect Tracking ==
58: 
59: === [[bugs.opensolaris.org>>http://bugs.opensolaris.org]] (BOO) ===
60: 
61: Lead: Bill Rushmore  
62: 
63: 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. Presently, bugs can only be submitted, and bugs in categories/subcategories available via BOO can be viewed. Existing bugs can not be updated. The basic plan is simple: 
64: * Deploy the bugs.opensolaris.org application on opensolaris.org servers in May 2009. (The application was previously owned and run elsewhere within Sun.) Note: Target was April, and engineering work is complete but have been waiting on internal work to change network information. 
65: * Start work on a list of enhancements in June 2009. Was May but moved to June because Bill has been helping with website transition work and waiting on the deployment. Note: Bugs logged against BOO are currently in Bugster. Need to decide whether to move them to defect.opensolaris.org and how to publish the list and information about progress.
66: 
67: |=BOO Accomplishments |=Date
68: |bugs.os.org deployed on os.org servers|May 2009
69: 
70: === [[defect.opensolaris.org>>http://defect.opensolaris.org]] ===
71: 
72: Lead: Bill Rushmore  
73: 
74: 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
75: [[requirements document>>http://www.opensolaris.org/sc/src/website/spec/dts-requirements/d-dts-requirements.txt]]. Four candidates were evaluated: RoundUp, Mantis BT, Eventum and Bugzilla. Bugzilla was chosen December 2007. defect.opensolaris.org is an instance of Bugzilla running in a zone on an opensolaris.org server. The current instance of bugzilla is an old development build, and it is not tied to the opensolaris.org membership database. An engineer will start looking at the work involved in turning this system into a product system in June 2009. Work will involve at least upgrading Bugzilla to a new version and integrating it with the new membership management application that will be available for opensolaris.org. Initially targeted May to get started, but Bill is also working BOO and the website transition, so it has pushed out. Note that administration of the use of defect.opensolaris.org will remain with the ’administrators’ currently on the tools-discuss mailing list.
76: 
77: |=defect.os.org Accomplishments |=Date
78: |defect.os.org upgraded to Bugzilla 3.4.1|August 2009
79: 
80: === Tools/Policies/Processes ===
81: 
82: 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.
83: 
84: |=Tool |=Date |=Status
85: |webrev|March 2009|can process bugs from bugster or bugzilla
86: |unified site search|  | 
87: 
88: == Community Contributions ==
89: 
90: === Sponsor Program ===
91: 
92: 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.
93: 
94: The [[request-sponsor table>>Main.request_sponsor]] contains all the requests and status information.
95: 
96: === Small-Bug-Fix-Submission ===
97: 
98: Project  Lead: Mark Nelson  
99: 
100: One idea for improving the sponsor program is to set up an ON engineering project on opensolaris.org
101: 
102: 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.
103: 
104: 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.
105: 
106: To enable this project, the following is needed:
107: 
108: * Definition of exactly what kinds of bugs qualify for this project;
109: * OpenRTI tool so external contributors can submit their own RTIs,
110: * Decision about whether bugs must all be logged in defect.opensolaris.org or whether Bugster bugs can be cited;
111: * Project processes defined and published;
112: * What else?
113: 
114: === Tools ===
115: 
116: 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 
117: model>>http://wiki.genunix.org/wiki/index.php/Gate_Pull_Model]] for consolidations like ON. A list and detail about each item on the list is the next step.
118: 
119: == Moving Source Repositories ==
120: 
121: 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.
OpenSolaris

Top Menu

Wiki code for Open Development Infrastructure

Search

Collectives

Community Group

Project

User Group

Subsites

Project opendev Pages
