OpenSolaris Developer Conference 4 May 2008

Defect Tracking Discussion Session
==================================

After a very brief background from me on Sun's historical defect tracking,
Shawn Walker gave a great overview of how OpenSolaris folks came to reach
the decision to use bugzilla.  This was followed by a lively discussion
which included questions on bugster and bugzilla, along with several
requirements for the defect tracking system going forward.

I promised to write up the notes, which took me an embarrassingly long
time to do... but here they are now.  While I haven't sent out the
notes, I had been working on a few of the things brought up internally
(like getting the bugster team into investigating reviving an old
public field, so we can have better public dialogue with bugster for
the time being).


Key requirements that aren't necessarily currently addressed
(correct me if I've got this wrong):

* OpenSolaris will soon have multiple releases to track, so some
   folks who are familiar with bugster's MultiRelease functionality
   see a need for this in bugzilla (or something similar)
   [swalker note: "Target Milestones" in bugzilla may satisfy this need]

* The defect tracking system must be available 24/7
        - needs data backup and recovery plans
        - needs at least basic administrator support in non "business"
          hours
        - can't be down for an extended period due to maintainer
          being on vacation or just offline.

* Folks want a more concrete transition plan. Right now, it is teams
   just deciding where they want to track bugs (bugzilla vs bugster)
   and the lack of direction and guidance is confusing and frustrating.
   [VAF note: To the best of my knowledge, software actually shipping
   in a revenue version of Solaris must be only tracked in bugster,
   works in progress/OpenSolaris only things may be tracked in bugzilla.
   exceptions noted below]

* Need federation ASAP. Several groups, like the Desktop team, are
   currently tracking bugs in several places, due to the fact that
   much of their code comes from upstream places & is pulled into
   OpenSolaris/Solaris. The issues with filing in multiple places,
   and keeping track of everything, are very complicated and time
   consuming. This is just prone to get worse for more teams.

* The community needs a bug lifecycle document for the OpenSolaris bugzilla
   interface and a definition of states.

   - Bugzilla does have hooks for online help that we should leverage.

* Need documentation on what is being tracked where (by project/cat/subcat/etc)





Valerie
-- 
Valerie Fenwick, http://blogs.sun.com/bubbva
Solaris Security Technologies,  Developer, Sun Microsystems, Inc.
17 Network Circle, Menlo Park, CA, 94025. 650-786-0461
_______________________________________________
tools-discuss mailing list
tools-discuss@opensolaris.org

Reply via email to