x

Main chapters

  1. LimeSurvey Cloud vs LimeSurvey CE
  2. LimeSurvey Cloud - Quick start guide
  3. LimeSurvey CE - Installation
  4. How to design a good survey (Guide)
  5. Getting started
  6. LimeSurvey configuration
  7. Introduction - Surveys
  8. View survey settings
  9. View survey menu
  10. View survey structure
  11. Introduction - Questions
  12. Introduction - Question Groups
  13. Introduction - Surveys - Management
  14. Survey toolbar options
  15. Multilingual survey
  16. Quick start guide - ExpressionScript
  17. Advanced features
  18. General FAQ
  19. Troubleshooting
  20. Workarounds
  21. License
  22. Version change log
  23. Plugins - Advanced
 Actions

The bugtracker and git: Difference between revisions

From LimeSurvey Manual

← Older editNewer edit →
Sammousa (talk | contribs)
49 edits
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://www.limesurvey.org/manual/index.php?title=The_bugtracker_and_git&oldid=267340"