Skip to main content

Notice: this Wiki will be going read only early in 2024 and edits will no longer be possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.

Jump to: navigation, search

Difference between revisions of "Modeling Project Workflow Conventions"

m (Include Bugzilla Number)
m (Bugzilla)
Line 13: Line 13:
 
* 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 '---').
 
* 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 '---').
  
===Prefix List===
+
====Prefix List====
 
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 [https://bugs.eclipse.org/bugs/describekeywords.cgi existing keywords] first.
 
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 [https://bugs.eclipse.org/bugs/describekeywords.cgi existing keywords] first.
  

Revision as of 14:07, 7 August 2006

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.

Bugzilla

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. Unfortunately, the section on Managing Requirements is incomplete, so Modeling project recommended practices are below:

  • The plan existing 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 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 '---').

Prefix List

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
  • [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.

NOTE: When using [Duplicate] be sure to make the new bug depend on the previous bug.

CVS

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:

  [149692] 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.

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 (e.g. [148402] 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 Documents

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:

Other Documents / External Links

Copyright © Eclipse Foundation, Inc. All Rights Reserved.