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

Modeling Project Workflow Conventions

Revision as of 18:51, 4 August 2006 by Codeslave.ca.ibm.com (Talk | contribs)

(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)

This document is a stub. Please add to it to make it grow.

Bugzilla

Naming

The following prefix conventions are used to when naming bugs to make searching easier and more obvious:

  • [Plan Item] -- Plan Item bugs
  • [releng] -- release engineering bugs
  • [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.

Workflow

1. NEW -- bug open or being worked
2. ASSIGNED -- fix is in CVS
3. FIXED -- fix is available in a build (set automatically during promotion)

In future - see bug 149692 - we'd like:

1. NEW -- bug open
2. ASSIGNED -- bug being worked
3. FIXED -- fix is in CVS
4. RELEASED -- fix is available in a build (set automatically during promotion)

CVS

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.

Plan Documents

Plan docs are simplified by linking to Bugzilla dynamically instead of statically listing bugs. Examples:

Other Documents

http://wiki.eclipse.org/index.php/Eclipse_Modeling_Framework_Technologies

Back to the top