Skip to main content

Notice: This Wiki is now read only and edits are no longer 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...")
 
 
(5 intermediate revisions by 3 users not shown)
Line 1: Line 1:
= Issue Tracking specifics for the EMF-IncQuery project =
+
= Issue Tracking specifics for the VIATRA 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 ==
+
== Component and version management ==
 +
Component maintainers are expected to follow issues related to their components. The default inboxes for the various components are set up as follows:
  
* Select the appropriate component, based on the description in BugZilla
+
{| class="wikitable"
* '''Version''': Select the one you are currently using, where you found the bug (you can check this in Help -> About Eclipse -> Installation Details)
+
! Component
* '''Severity''': Select one other than ''"enhancement"''
+
! Default owner
* Write a clear summary
+
|-
* Stating your '''Xtext version''' in the issue description helps
+
! Query         || viatra-query@eclipse.org
* If you can, provide steps to reproduce, any workarounds you know of or examples where the bug occurs
+
|-
 +
! Transformation || viatra-transformation@eclipse.org
 +
|-
 +
! Addons || viatra-inbox@eclipse.org
 +
|-
 +
! CEP || viatra-cep@eclipse.org
 +
|-
 +
! DSE || viatra-dse@eclipse.org
 +
|-
 +
! Integrations || viatra-inbox@eclipse.org
 +
|-
 +
! Obfuscator || viatra-inbox@eclipse.org
 +
|}
  
== Creating feature request ==
+
In [https://bugs.eclipse.org/bugs/userprefs.cgi?tab=email Bugzilla settings] in the ''User Watching'' part you can subscribe to all issues created (that is not assigned by default to somebody) in that component.
 
+
* 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 ==
 
+
* The *version* attribute means the lowest version where the specified change is relevant:
* '''Do not use version numbers ending in .x''', they were created by mistake and not used any more
+
** In case of bugs, the earliest version it was identified/reproduced.
 +
** In case of enhancements, the version the missing feature was detected by the reporter.
 +
** Only update the version attribute, if it was reproduced in an earlier version.
 
* When planning a release, assign milestones to the issues which are part of the next release
 
* 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
 
* When a milestone is completed, do the following for all corresponding open issues
 
** move to a later milestone if still planned for the release
 
** 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
+
** set the milestone to FUTURE or any later milestone (if available) 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
 
* 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:
+
* The milestone version of an issue therefore means:
 
** '''New''': the version it is reported for
 
** '''New''': the version it is reported for
 
** '''Open''': the version it is planned to be fixed or added
 
** '''Open''': the version it is planned to be fixed or added
 
** '''Resolved''': the version where it has been fixed or added
 
** '''Resolved''': the version where it has been fixed or added

Latest revision as of 06:08, 9 December 2018

Issue Tracking specifics for the VIATRA project

For user documentation on creating issues, see here

Component and version management

Component maintainers are expected to follow issues related to their components. The default inboxes for the various components are set up as follows:

Component Default owner
Query viatra-query@eclipse.org
Transformation viatra-transformation@eclipse.org
Addons viatra-inbox@eclipse.org
CEP viatra-cep@eclipse.org
DSE viatra-dse@eclipse.org
Integrations viatra-inbox@eclipse.org
Obfuscator viatra-inbox@eclipse.org

In Bugzilla settings in the User Watching part you can subscribe to all issues created (that is not assigned by default to somebody) in that component.

Managing issue life-cycle

  • The *version* attribute means the lowest version where the specified change is relevant:
    • In case of bugs, the earliest version it was identified/reproduced.
    • In case of enhancements, the version the missing feature was detected by the reporter.
    • Only update the version attribute, if it was reproduced in an earlier version.
  • 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 FUTURE or any later milestone (if available) 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 milestone 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