Skip to main content
Jump to: navigation, search

Difference between revisions of "EMF Facet/Bug Process"

(Bug process)
 
(18 intermediate revisions by 2 users not shown)
Line 1: Line 1:
 
= Bug process =
 
= Bug process =
  
The user:
+
== The user reports a "bug" ==
* create a bug
+
* Report a bug (where bug is a bugzilla item)
 
** specify the version in which the bug appears
 
** specify the version in which the bug appears
  
Line 8: Line 8:
 
* Mark the bug with one of the following priority:
 
* Mark the bug with one of the following priority:
 
** P1: Urgent
 
** P1: Urgent
** P2: Has to fixed before the next minor release
+
** P2: Has to be fixed before the next minor release
 
** P4: Should be fixed before the next minor release
 
** P4: Should be fixed before the next minor release
** P5: No fixed planned for the next minor release
+
** P5: No fix planned for the next minor release
  
 
P3 is the default priority value : reserved to indicate that the bug has not be prioritized.  
 
P3 is the default priority value : reserved to indicate that the bug has not be prioritized.  
  
The contributer :
+
== The committer checks the bug report ==
 
* If the version number is empty:
 
* If the version number is empty:
 
** Ask the version to the user
 
** Ask the version to the user
* Try reproduce the bug
+
* Try to reproduce the bug
 
** If the contributer cannot reproduce the bug
 
** If the contributer cannot reproduce the bug
 
*** the bug mark the bug as "worksforme"
 
*** the bug mark the bug as "worksforme"
 
** If the contributer can reproduce the bug
 
** If the contributer can reproduce the bug
 
*** Adjust the version number to the oldest maintained branch on which the bug appears
 
*** Adjust the version number to the oldest maintained branch on which the bug appears
*** Assign the bug to himself
 
*** Create a patch containing:
 
**** the bug fix
 
**** the documentation update (including the "New and Noteworthly")
 
**** unit tests
 
*** attach the patch the bug
 
**** confirm, in the attachment comment, that him contribution complies with http://www.eclipse.org/legal/CoO.php
 
  
The committer :
+
== The contributer proposes a patch ==
* Commit the patch
+
* Create a git commit
* Add a comment the bug attachment indicating the commit id.
+
** containing:
* Mark the committed attachment iplog+
+
*** the bug fix
* Mark the '''not''' committed attachment iplog-
+
*** the documentation update (including the "New and Noteworthly")
 +
*** unit tests
 +
** and having a well-formed comment:
 +
*** the first line contains the bug label : Bug <bug-id> - <bug-label>
 +
*** lines containing the explanations of the commit
 +
*** an empty line
 +
*** the [http://stackoverflow.com/questions/1962094/what-is-the-sign-off-feature-in-git-for| "signed-off-by"] line to confirm that him contribution complies with http://www.eclipse.org/legal/CoO.php
 +
 
 +
Bug %bug-id% - %bug-label%
 +
 +
Signed-off-by: %firstName% %lastName% <%e-mail%>
 +
 
 +
* push this commit to [[Gerrit]]
 +
 
 +
== The committer reviews the patch ==
 +
* Assign the bug to himself
 +
* Do the code review and vote via Gerrit
 +
** Check that the copyright header is well-formed
 +
** The contributor sections have been updated
 +
** The commit message contains the "Signed-off-by"
 +
* Submit the path via Gerrit
 +
* Add a comment to the bug attachment indicating the commit id.
 
* Mark the bug as "RESOLVED" "FIXED"
 
* Mark the bug as "RESOLVED" "FIXED"
 
* Set the "Target Milestone" field
 
* Set the "Target Milestone" field
  
The user:
+
== The user checks the fix ==
* Get the next milestone.
+
* Get the next milestone build (or integration build).
 
* Check that the bug is fixed.
 
* Check that the bug is fixed.
 
** If the bug is fixed
 
** If the bug is fixed
Line 46: Line 60:
 
*** Reopen the bug.  
 
*** Reopen the bug.  
  
The project leader:
+
== The project leader cleans the bugzilla entries ==
 
* Before the release (in May)
 
* Before the release (in May)
** Closed the bugs which have not be closed by the user.
+
** Close the bugs which have not be closed by the user.

Latest revision as of 09:56, 25 May 2015

Bug process

The user reports a "bug"

  • Report a bug (where bug is a bugzilla item)
    • specify the version in which the bug appears

The project leader:

  • Mark the bug with one of the following priority:
    • P1: Urgent
    • P2: Has to be fixed before the next minor release
    • P4: Should be fixed before the next minor release
    • P5: No fix planned for the next minor release

P3 is the default priority value : reserved to indicate that the bug has not be prioritized.

The committer checks the bug report

  • If the version number is empty:
    • Ask the version to the user
  • Try to reproduce the bug
    • If the contributer cannot reproduce the bug
      • the bug mark the bug as "worksforme"
    • If the contributer can reproduce the bug
      • Adjust the version number to the oldest maintained branch on which the bug appears

The contributer proposes a patch

  • Create a git commit
    • containing:
      • the bug fix
      • the documentation update (including the "New and Noteworthly")
      • unit tests
    • and having a well-formed comment:
Bug %bug-id% - %bug-label%

Signed-off-by: %firstName% %lastName% <%e-mail%>

The committer reviews the patch

  • Assign the bug to himself
  • Do the code review and vote via Gerrit
    • Check that the copyright header is well-formed
    • The contributor sections have been updated
    • The commit message contains the "Signed-off-by"
  • Submit the path via Gerrit
  • Add a comment to the bug attachment indicating the commit id.
  • Mark the bug as "RESOLVED" "FIXED"
  • Set the "Target Milestone" field

The user checks the fix

  • Get the next milestone build (or integration build).
  • Check that the bug is fixed.
    • If the bug is fixed
      • Close the bug.
    • If the bug is not fixed
      • Reopen the bug.

The project leader cleans the bugzilla entries

  • Before the release (in May)
    • Close the bugs which have not be closed by the user.

Back to the top