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 (Bugzilla)
m (Include Contributor ID)
Line 39: Line 39:
 
   [148402] mgolubev - Do not create unlimited number of font/color resources
 
   [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.
+
This is required per the IP log tracking policy, and will allow for the generation of much of this log file.  With that, the addition of the 'contribution' keyword to bugs that have had committed patches will facilitate reporting.
  
 
==Plan Documents==
 
==Plan Documents==

Revision as of 11:44, 23 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. 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 also 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 will rely on the 'plan' keyword.
  • 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).

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 (optional, used in addition to 'plan' keyword)
  • [releng] -- release engineering bugs (adding a 'releng' component to your product list is recommended)
  • [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? another idea is 'clone')

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. 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 - however these last two are not currently supported by the generator tools.

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:

  [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. With that, the addition of the 'contribution' keyword to bugs that have had committed patches will facilitate reporting.

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

Back to the top