Jump to: navigation, search

Difference between revisions of "Modeling Project Workflow Conventions"

Line 41: Line 41:
* [http://www.eclipse.org/emf/docs/dev-plans/emf_project_plan_3.0.html EMF 3.0 Plan Doc (Europa)]
* [http://www.eclipse.org/emf/docs/dev-plans/emf_project_plan_3.0.html EMF 3.0 Plan Doc (Europa)]
==Other Documents==
==Other Documents / External Links==
* http://wiki.eclipse.org/index.php/Eclipse_Modeling_Framework_Technologies
* http://www.eclipse.org/projects/dev_process/bugzilla-use.php

Revision as of 17:53, 4 August 2006

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



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.


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)


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 / External Links