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 "VIATRA/DeveloperDocumentation/IssueTracking"

(Created page with "= Issue Tracking specifics for the EMF-IncQuery project = Use [https://bugs.eclipse.org/bugs/enter_bug.cgi?product=Incquery Bugzilla] or Mylyn to report bugs or create featur...")
 
Line 1: Line 1:
 
= Issue Tracking specifics for the EMF-IncQuery project =
 
= Issue Tracking specifics for the EMF-IncQuery project =
  
Use [https://bugs.eclipse.org/bugs/enter_bug.cgi?product=Incquery Bugzilla] or Mylyn to report bugs or create feature requests.
+
For user documentation on creating issues, see [[EMFIncQuery/UserDocumentation/IssueTracking|here]]
 
+
== Reporting bugs ==
+
 
+
* Select the appropriate component, based on the description in BugZilla
+
* '''Version''': Select the one you are currently using, where you found the bug (you can check this in Help -> About Eclipse -> Installation Details)
+
* '''Severity''': Select one other than ''"enhancement"''
+
* Write a clear summary
+
* Stating your '''Xtext version''' in the issue description helps
+
* If you can, provide steps to reproduce, any workarounds you know of or examples where the bug occurs
+
 
+
== Creating feature request ==
+
 
+
* Select the appropriate component, based on the description in BugZilla
+
* '''Version''': Select ''"unspecified"'', since we don't know if or when it can be added
+
* '''Severity''': Select ''"enhancement"''
+
* Write a clear summary
+
* Provide a real use case for the feature and preferable some examples on how you imagine it
+
  
 
== Managing issue life-cycle ==
 
== Managing issue life-cycle ==

Revision as of 05:51, 5 June 2014

Issue Tracking specifics for the EMF-IncQuery project

For user documentation on creating issues, see here

Managing issue life-cycle

  • Do not use version numbers ending in .x, they were created by mistake and not used any more
  • When planning a release, assign milestones to the issues which are part of the next release
  • When a milestone is completed, do the following for all corresponding open issues
    • move to a later milestone if still planned for the release
    • set the milestone to unspecified and advance the version number if not planned for the release
  • Do the same as above with any open issue when it is no longer considered for its current milestone
  • The version of an issue therefore means:
    • New: the version it is reported for
    • Open: the version it is planned to be fixed or added
    • Resolved: the version where it has been fixed or added

Back to the top