Actions

The bugtracker and git: Difference between revisions

From LimeSurvey Manual

No edit summary
(updated workflow and formatting)
Line 2: Line 2:
This article should help developers on the LimeSurvey when resolving issues.
This article should help developers on the LimeSurvey when resolving issues.


General process outline.
General process outline:


1. Bug reported by user.
# Bug reported by a user in [https://bugs.limesurvey.org Mantis]
# Bug assigned to a developer (by the developer or someone else)
# Bug fixed and a PR (pull request) made at github.com
# Mantis ticket status changed to '''ready for code review'''
# When creating the PR, please assign reviewer (DenisChenu or gabrieljenik for bugs, developer recommended by Github for features)
# If the code review fails, reviewer puts comments in the PR what needs to be fixed
# After successful code review, quality assurance tests and verifies the bugfix/feature
# If testing fails, quality assurance puts comments in the Mantis ticket
# Finally if all is well, quality assurance merges the PR and code gets published with a new version
# Mantis ticket status changed to '''resolved''' and later '''closed'''


2. Bug assigned to developer (by the developer himself or someone else)
This method of working should allow for efficient bug fixing with multiple developers.
 
3. Bug fixed github.com
 
4. Issue assigned to LimeSurvey repository owner (c_schmitz), status set to resolved.
 
5. When a new version is released c_schmitz closes the resolved bugs.
 
This method of working should allow for efficient bug fixing with multiple developers without getting c_schmitz overworked..?


Please respond on what you think of this process, or what should be changed.
Please respond on what you think of this process, or what should be changed.

Revision as of 10:23, 23 October 2023

This article should help developers on the LimeSurvey when resolving issues.

General process outline:

  1. Bug reported by a user in Mantis
  2. Bug assigned to a developer (by the developer or someone else)
  3. Bug fixed and a PR (pull request) made at github.com
  4. Mantis ticket status changed to ready for code review
  5. When creating the PR, please assign reviewer (DenisChenu or gabrieljenik for bugs, developer recommended by Github for features)
  6. If the code review fails, reviewer puts comments in the PR what needs to be fixed
  7. After successful code review, quality assurance tests and verifies the bugfix/feature
  8. If testing fails, quality assurance puts comments in the Mantis ticket
  9. Finally if all is well, quality assurance merges the PR and code gets published with a new version
  10. Mantis ticket status changed to resolved and later closed

This method of working should allow for efficient bug fixing with multiple developers.

Please respond on what you think of this process, or what should be changed.

Retrieved from "http://manual.limesurvey.org/index.php?title=The_bugtracker_and_git&oldid=267340"