Modeling Project Workflow Conventions
This document describes some recommended practices when using Bugzilla that will provide the Modeling project with improved reporting and planning automation. It is expected that all Committers on Modeling projects will read and follow these conventions in order to maximize our overall efficiency and provide accurate project plans, as is required by the Development Process.
General guidelines for using Bugzilla on Eclipse projects is found here, with a potential change coming to the states we use described in this bug 149692. Some refinements to this document for Modeling are below:
- The 'Version' field should indicate the product version a bug is found in, or enhancement request filed against. This is distinguished from the 'Target Milestone' field, which is used to indicate when a fix is planned to be completed.
Unfortunately, the section on Managing Requirements in the aforementioned document is incomplete, so Modeling project recommended practices are below:
- The plan keyword should be used to indicate items expected to be completed in the upcoming release, as refined by the following fields. Alternatively, projects may wish to continue prefixing the Summary field with [Plan Item]. Note that the use of the keywords improves search accuracy and eliminates "pollution" of the Summary line. The reporting query should look for either a keyword or prefix.
- The 'Assigned To' field will indicate the individual committed to delivering plan items, while the absence of an individual name (e.g. set to the default component inbox) indicates proposed items.
- The 'Target Milestone' field should indicate the milestone an item is expected to be resolved in (e.g. '2.0 M1'), or simply to the major version number if the target milestone is not yet known (e.g. '2.0'). During milestone release planning iterations, items should be reviewed and milestones updated to reflect work expected to be completed in the next iteration. Setting the 'Target Milestone' field to blank or a future release stream indicates a deferred item.
To summarize the process:
- Items that Committers would like to appear on the project plan need to be indicated using the plan keyword or [Plan Item] prefix in the summary.
- Use the 'Assigned To' field to indicate committed or proposed status.
- Use the 'Target Milestone' field to indicate first the release (e.g. '2.0'), then a specific milestone (e.g. '2.0 M3'), and deferred items (set to '---' or future stream).
The following prefix conventions are used to when naming bugs to make searching easier and more obvious. When considering new prefixes, please check the list of existing keywords first.
- [Plan Item] -- Plan Item bugs (prefer 'plan' keyword)
- [releng] -- release engineering bugs (why not add a 'releng' component to your product list?)
- [Duplicate] -- to mark a new bug for an existing fix as being backported to a maintenance stream. This makes it easy to find bugs by name and know which one was the backport and which the original. (not confusing with DUPLICATE resolution? what about using [backport] or asking for 'backport' as official keyword?)
NOTE: When using [Duplicate] be sure to make the new bug depend on the previous bug.
While basic information on using CVS is found here, below are some details for using CVS to promote the automation of release notes, ip logs, etc.
Include Bugzilla Number
We commit fixes with comments preceded by the bug number, as in:
 Fixed something in this file
where 149692 is the bug opened regarding the fix. By doing this we are able to generate release notes and bug-specific delta logs dynamically from CVS logs. Alternatively, it should be possible to enter bug with prefixed # sign, or both # and brackets (e.g. #149692 or [#149692]) in order to account for legacy techniques.
Include Contributor ID
If you're submitting a patch that was contributed through Bugzilla, you must also include that contributor's ID in the CVS comment, as in:
 mgolubev - Do not create unlimited number of font/color resources
This is required per the IP log tracking policy, and will allow for the generation of much of this log file.
Plan docs are simplified by linking to Bugzilla dynamically instead of statically listing bugs, which is the motivation for outlining the above process guidelines. Examples: