OpenSolaris: Defect tracking relationships
By sch on May 23, 2007
Just prior to the Board election, we ran a poll of the core
contributors to get some sense of what one active subset
felt were the five most pressing obstacles to open development. Dan
just issued an initial Beta of a
webrev-based approach, derived from
his earlier experiment on http://cr.grommit.com, so that's a starting
point for Priority 3. The Board is tackling, in full public view on
ogb-discuss, Priority 4: there's OGB/2007/001, Project
and OGB/2007/002, Community and Project
as two significant chunks of a stablized reorganization. Priority 2,
the deployment of a "request to integrate" system, is
somewhat gated on ON and sister consolidations' switch to Mercurial,
being pursued in the
aspect of workflow that isn't required by all of the hosted
consolidations. Priority 5, the deployment of an
opensolaris.org-hosted wiki, is in a requirements gathering phase over
That leaves Priority 1, the deployment of a public bug tracking system. Bug tracking has loomed over the OpenSolaris effort for pretty much its entire implementation phase; we've known that aspects of the current bug tracking methodologies impact many parts of Sun's business, and that any solution will require the identification of which entanglements are strategic—meaning that there's a requirement for any new system—and which are accidental—meaning that there's only some transition cost, as the entangled system can be adjusted to consume information in some designed fashion. So, as part of getting a set of draft requirements together for discussion, I thought I would work through some of the issues facing defect tracking as we move to open development. Most of these points are about the developer–distribution (or upstream–downstream) interface that a defect tracking system (DTS) or defect tracking architecture represents.
The primary requirement that a distribution has on their DTS is some ability to maintain confidential data associated with each tracked defect. Let's call that database a proprietary annotation system (PAS)—the data within it capture the customer histories associated with various defects or collections of defects ("products"?) represented in the system. The DTS, meanwhile, is meant to be neutral across all participants, developers and distribution assemblers, and unconcerned with non-technical characteristics of the defect.
This contrast allows us to postulate a set of relationships among various active DTSs and PASs for an open development community.
The association of confidential information with an existing defect looks something like
Of course, in the OpenSolaris case, SMI's annotations become just one potential PAS; other distributions may also choose to annotate publicly known ("community tracked") defects:
One requirement that we've heard during preliminary discussions with the various teams is there must be some ability to search the entirety of the product-relevant portion of the DTS. One possibility is that each PAS operator builds a search corpus that combines the upstream DTS with the PAS content. A potentially more economic alternative would be to allow the the associations to be bidirectional (so that an indexer with authorizations allowing it to access one or more proprietary annotation systems can present a complete defect corpus). Making the existence of the annotations public does not seem like a significant leak of proprietary information, while the existence of annotations might be a useful measure of defect significance. (It is probably worth explicitly stating that having a complete defect corpus for searching does not imply that use of a single DTS is the only means of obtaining such a corpus.)
These associations are more complex objects than the current See Also links in typical monolithic DTSes, in that they carry one or more mappings of status and responsibility between the DTS and each PAS. Potentially, this capability could lead to more precise handling of release readiness, in that a query involving a group of PAS-tracked defects could indicate that one or more stoppers are blocking the release of a certain version of the tracked product. Of course, prior to open development, the Solaris organization has historically managed that fairly well for its products, so why is it worth discussing?
Well, for OpenSolaris today, the set of defects in our own DTS isn't the complete set of relevant defects for product release. In fact, as examples, Solaris tracks the defects, branches, and patches for GNOME, Mozilla Firefox, and Perl, among others. That is, Sun's current combined DTS/PAS, Bugster, is in the following relationships with an upstream source
when the product is affected by an upstream-sourced component, and
when a customer is affected by an upstream-sourced component. There's also an awkward local cost since upstream state is usually tracked manually (or possibly via custom scripting).
We can choose to apply this tracking need to our second defect/annotation figure above, in two ways: we can track the OpenSolaris consolidation defects as a peer of other upstream DTSs
or, more interestingly, we can allow community management of the relevance of upstream defects, like the following
(A distribution may not choose to annotate the public DTS record on an upstream bug, but may instead choose to annotate on the upstream DTS record directly. Ignoring the community signal when it has a mismatch with distribution priorities seems likely; using it as a guide when no conflicting principle exists seems like a safe course as well.)
I think that introducing these kinds of associations allows us to solve a large class of defect tracking problems that are currently impacting the OpenSolaris space. (Obviously there are issues, too--for instance, one could introduce association cycles (that clients must detect).) I would expect that the confidentiality issue impacts all of the distributions pulling from OpenSolaris consolidations (and probably, more generally, all groups looking at open development): I believe every distribution has customers of some kind. The importance of upstream relationships may presently be operating environment-specific, although I know other groups are also dependent on some number of OSS components.