Skip to content
GitLab

Development process · Changes

Page history
updated development workflow, fixed link to source control policies authored by Peter Krautzberger's avatar Peter Krautzberger
Show whitespace changes
Inline Side-by-side
Development-process.md
View page @ 3e69d714
......@@ -31,13 +31,15 @@ Accepted bugs go into the Development workflow.
### Development Workflow
> This is an overview over the process outside our [[Source control policies]] which follow [this branching model](nvie.com/posts/a-successful-git-branching-model/).)
For each Accepted bug, the developer identifies the problem and/or *outlines a design* to address the issue. Once a design outline is complete, the developer marks the issue as **Ready for Development** and notifies the team. For simple issues, the developer may be able to outline a design in the issue, and setting the status is mostly a heads up to avoid conflicts. For more substantial issues, the developer is responsible for leading a discussion on mathjax-dev, writing design pages here, and obtaining consensus on the implementation plan. In these cases, setting the status to Ready for Development is a "last call" and denotes the end of the design phase.
When development begins, the issue is moved to **In Development**.
When development is complete, the developer prepares a **testing branch** (see the [[source control plan]]) and again notifies the team and tags the issue as **Ready for Review**. A typical way of handling this in open source projects is that at least one senior project developer has to review and sign off on all new work. The code is also tested in the testing branch. If problems arise, they may spawn new issues, or merely send the original issue back to **In Development**. Ideally, at least one automated test should be written to check the issue and in that case the QA flag is changed to **In Testsuite**. If that's too difficult or not necessary, the QA flag may be changed to **Do Not Write Automated Test** and the issue is then only tested manually.
When development is complete, the developer merges the working branch into the **develop branch** (see the [[Source control policies]]), again notifies the team (via a pull request) and tags the issue as **Ready for Review**. At least one senior project developer has to review and sign off on all new work. The code is also tested in the develop branch. If problems arise, they may spawn new issues, or merely send the original issue back to **In Development**. Ideally, at least one automated test should be written to check the issue and in that case the QA flag is changed to **In Testsuite**. If that's too difficult or not necessary, the QA flag may be changed to **Do Not Write Automated Test** and the issue is then only tested manually.
Once the issue is tested, it goes to **Ready For Release**. Issues in this state are complete, but have not been merged into the master or release line for which they are destined yet. For now, [Davide](https://github.com/dpvc) will be responsible for making all merges of **Ready For Release** issues into the MathJax repo.
Once the issue is tested, it goes to **Ready For Release**. Issues in this state are complete, but have not been merged into the develop or release line for which they are destined yet. For now, [Davide](https://github.com/dpvc) will be responsible for making all merges of **Ready For Release** issues into the MathJax repo.
Once an issue has been merged, it will get the **Fixed** tag, and **Closed**.
......