ISO 10303 usage of Bugzilla

From WikiSTEP

Jump to: navigation, search

Introduction

'This page is under construction


An instance of Bugzilla [1] is used to manage and track the issues raised against several of the standards developed by ISO TC 184/SC 4. Presently those standards include ISO 10303, ISO 13584, ISO 29002 as well as SC4 standing documents. The instance is at: http://wikistep.org/Bugzilla/.

Contents

Getting started with Bugzilla--create an account

Bugzilla is web based. In order to access the SC4 instance of Bugzilla, you must be a registered user.
Because of administrative (i.e., security, copyright...) issues, you must request an account to be created.
Currently the details of the account creation process are being updated. In the interim, send an email to Lothar Klein or Thomas Thurman. They will process the request and assign an initial password.
If you don't know their email address, please contact the ISO TC 184/SC 4 secretariat: (http://www.iso.org/iso/home/standards_development/list_of_iso_technical_committees/iso_technical_committee.htm?commid=54158)

and reference a request for access to 10303 instance of bugziila. They will forward your request to Mr. Klein and Mr. Thurman

Constraints
A valid email address must be used as a userid.
The password will be sent in plain text email so you must change your password once you log in.

Default SC4 bug life cycle

In the lifecycle of SC4 standards there arise several types of issues that must be managed. The issues typically are ballot issues, working group developmental issues, and issues raised by the user community.

Figure 1 illustrates the high level states of a bug against an SC4 document.

  • In order to create a bug, a user must enter some meta-data about the issue and a description.
    • Bugzilla administrators as well as project leaders and developers periodically review the Bugzilla database to enable workflow.
  • Once a bug is created (as noted by being CONFIRMED), a developer is eventually assigned to it and accepts the assignment, causing the state to change to IN_PROGRESS.
  • Once a bug is resolved, the developer marks it RESOLVE, FIXED and assigns it for QA review.
  • Once QA review is complete, the bug is assigned to the convener for review.
    • QA is typically the project leader but may be assigned by SC4.
  • Once the convener has completed review, the convener marks the bug VERIFIED.
  • Once the document is published by ISO the bug is CLOSED. Typically the convener will assign this task to a project lead.
Figure 1 Bug workflow

Bugzilla fields

The Bugzilla native database structure is not perfectly aligned with SC4 usage. Therefore it is critical for successful application to keep in mind the Bugzilla structure and nomenclature, and how they are mapped to the SC4 use cases.

Summary

User defined. See Collector Bugs for WG12 usage.

Product

Bugzilla is organized by products.

"product" is a native Bugzilla field. The following products are currently available. More can be added.

  • ISO 10303: All parts of ISO 10303
  • ISO 10303 Recommended Practices and Guides:
  • ISO 13584: All parts of ISO 13584
  • ISO 29002: All parts of ISO 29002
  • SC4 standing documents
  • stepmod environment and utilities:

Component

  • Each product may have one or more Bugzilla 'component' that is an ISO or other organization (e.g., CAx-IF) part. For example, ISO 10303-41 is considered in the context of Bugzilla to be component 0041.

Version

  • In SC4 usage, Version is the version of the Bugzilla 'component', not of the overall product.
  • This is the consequence of a design decision made years ago to treat each SC4 standard as a product.
  • Because SMRL is a component of 10303 each bug raised against a part included in a Change Request shall use the Change request number as the version.
  • Example: CR9 is a version of the SMRL component of ISO 10303, and issues raised during ballot review against e.g., part 41 (included in CR9) shall identify CR9 as the version.
  • Example: ISO 10303-1109 edition 2 has an error in a bibliography entry. The version entered during bug creation shall be Ed2
  • There is a limitation on the number of characters allowed for a version.

Target Milestone

  • This is the planned publication target for the change that will fix the issue.
  • This value is actively managed by the convener and project leaders during development.

The milestones correspond to a publication or SMRL change request in which the issue has been or is planned to be resolved. E.g SMRLv5, CR10.

WG12 has migrated to using CR numbers and SMRL numbers for fine publication control. Projects often assign AP versions as milestones. For management purposes, the milestones eventually migrate to a consistent set under convener guidance.

  • If the issue is closed, then the milestone reflects the release in which the issue was addressed
  • If the issue is open, then the milestone reflects the target release in which the issue is to be addressed

Platform

The platform field indicates the section of the document that the issue relates to.

OS

The OS field indicates what development life cycle the bug is raised within. The following values can ce used:

Internal
Internal project raised; Up to project to manage application of this value.
Informal implementor review
Formal implementor review
Formal project team review
Convener review
Maintenance Team review
An issue raised as part of the Maintenance Team review
Ballot Comment
An issue raised as a result of a Ballot Comment. See Ballots.
Convener review
SC4 review
An issue raised as part of the SC4 review (e.g., at an SC4 meeting)
ISO Pre_review
An issue raised by ISO CS as part of their editorial reviews
ISO Review
An issue raised by ISO CS as part of their editorial reviews
Ballot comment
An issue raised during a ballot
SEDS
An issue raised as a result of a SEDS. See SEDS.

depends on

identifies other bug(s) this bug depends on

Keyword

The keyword field identifies the AP projects associated with the bug.

  • Example: Most bugs in CR9 are associated with AP 209, AP 210 and AP 242.

Keyword field may also be extended for sub-project management for complex developments.

Priority

This field describes the importance and order in which a bug should be fixed. This field is utilized by the programmers/engineers to prioritize their work to be done. The available priorities range from P1 (most important) to P5 (least important). To date not much used.

Severity

This field describes the impact of a bug. Its use is not really regulated; just use 'normal' unless you are an expert.
Blocker-Blocks development and/or testing work
Critical-crashes, loss of data, severe memory leak
Major-major loss of function
Normal-regular issue, some loss of functionality under specific circumstances
Minor-minor loss of function, or other problem where easy workaround is present
Trivial-cosmetic problem like misspelled words or misaligned text
Enhancement-Request for enhancement

WG Identifier

Identifies a document by its working group number. Used in the case where the tuple {product, component, version} may not be sufficiently explicit for users.

Other Affected component

Identifies other components affected by the issue or by the solution. Used mainly to assist in searching for bugs related to a document.

BO-Model details

none yet

See Also

This allows you to refer to bugs that are related but that relationship is not a dependency relationship. You can enter a URL to a bug in the 'Add Bug URLs' field to note that that bug is related to this one. You can enter multiple URLs at once by separating them with a comma. Where there is a clear dependency, (i.e., a module requires an update to an IR before it can be published), it is better to use the Depends on and Blocks fields.

SEDS

The SC4 Enhancement and Discrepancy System (SEDS) provided a capability for users to report errors and raise issues against SC4 standards. Bugzilla replaced the web based support for SEDS. The use of SEDS as an option is provided for legacy support.

Ballots

Bugzilla is considered an official ballot comment repository

Recording ballot comments Ballot comments should be recorded as Bugzilla issues as follows: Create a bug which collects all the ballot comments bugs i.e. have them as blockers Raise a bug for each ballot comment. Use the following fields as follows Summary: start summary with: "Ballot_UK: " "Ballot_US:" etc OS: "Ballot Comment" Comment: the ballot comment itself.

Integration with STEPmod

The STEP Module Repository (STEPmod) is a collection of resources tagged in XML to serve as the core of a modular environment for developers of STEP, a family of product data exchange standards. STEPmod may be accessed at: stepmod.sourceforge.net Information on how to access and use STEPmod may be accessed at: http://stepmod.cvs.sourceforge.net/viewvc/stepmod/stepmod/help/index.htm Figure 3 illustrates correspondence between critical fields in the SC4 instance of Bugzilla and critical tags in STEPmod.

When a developer commits a file to STEPmod CVS, the Bugzilla comment is referenced in the commit message.

When a developer commits a file to STEPmod CVS, a comment is created in Bugzilla

  • Example from bug #4437 comment #1: arm.exp updated rev 1.61


Figure 3 correspondence between STEPmod and Bugzilla

Collector bugs

Collector bugs are explicitly represented in publication_index.xml as an attribute of the <module>, <resource_doc, <bo> elements. This allows the project leader to perform more effective cross-checking to ensure that all desired issues are addressed for a milestone (by extracting data from publication_index.xml and comparing that data to the data in bugzilla for that document).

See Collector Bugs for examples.

Integration with Document workflow

Figure 2 illustrates using Bugzilla as a control mechanism in document development. The project team is responsible for addressing issues and resolving them. The convener is responsible for issue verification and document release. The convener may delegate the responsibility for closing bugs once a document is published.

Figure 2 SC4 Document centric workflow

Example of creating new bug

Minimal data option

This is the case where the Bugzilla new page shows a few fields. In the upper left there is a link:"Show Advanced Fields"

  1. login to Bugzilla
  2. Select 'NEW' from top menu
  3. pick "ISO 10303"
  4. picK "0041"
  5. pick 'Version" => Ed3
  6. Enter brief description of bug in Summary
  7. Enter detailed description
  8. Add an attachment if desired
  9. pick "normal" for "Severity"
  10. pick "Resource EXPRESS" for "Hardware"
  11. pick "OS" value according to OS life cycle stage that is relevant.

Additional data option

If it is desired to provide more data, select "Show Advanced Fields"

The "Show Advanced Fields" link will change to "Hide Advanced Fields"

With advanced fields set, it is allowed to set "depends on", "Keywords" and other fields.

"Target milestone" may be set if known or commonly understood/ agreed to. Otherwise the project will review the bug and propose a milestone.

"Assignee" If the developer is known fill in part of their email address (usually family name"). Bugzilla will search and prompt for userid for the assignee after the bug is 'submitted;.

"CC" if the other team members who desire knowledge of or expressed interest in the topic.

Generally, it is better to populate only the fields you are really concerned about. The project or Bugzilla administrator in concert with the convener often change fields for project management purposes.

SC4 does NOT use "deadline", "Orig. Est.:" fields.

Personal tools