Skip to content
GitLab

Development process · Changes

Page history
Updated Development process (markdown) authored by fred-wang's avatar fred-wang
Hide whitespace changes
Inline Side-by-side
Development-process.md
View page @ ea9b9ffd
...@@ -15,7 +15,6 @@ Note that we are using our tracker for three distinct purposes: ...@@ -15,7 +15,6 @@ Note that we are using our tracker for three distinct purposes:
* Ready For Development (investigation is complete, and a solution designed) * Ready For Development (investigation is complete, and a solution designed)
* In Development * In Development
* Ready for Review (a testing branch has been prepared for review and testing) * Ready for Review (a testing branch has been prepared for review and testing)
* In Testing (the issue has passed the review and is being tested)
* Ready for Release (the issue has passed testing, and is ready to merge to master) * Ready for Release (the issue has passed testing, and is ready to merge to master)
3. Quality assurance management - we will use tags to indicate whether the bug requires testcases and give the status of the development of unit tests. The labels that accomplish this are: 3. Quality assurance management - we will use tags to indicate whether the bug requires testcases and give the status of the development of unit tests. The labels that accomplish this are:
* Testcase Wanted: a reduced testcase demonstrating the issue is expected. * Testcase Wanted: a reduced testcase demonstrating the issue is expected.
...@@ -35,9 +34,7 @@ For each Accepted bug, the developer identifies the problem and/or *outlines a d ...@@ -35,9 +34,7 @@ For each Accepted bug, the developer identifies the problem and/or *outlines a d
When development begins, the issue is moved to **In Development**. 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. 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.
Once the code has passed review, it is marked as **In Testing**. The code is tested in the testing branch. For now, the reviewer will do the testing. We hope to develop a battery of automated tests, but details will have to be worked out. In future, we may have dedicated QA people, in which case an issue going into this phase is the signal for them to do the testing.If problems arise, they may spawn new issues, or merely send the original issue back to In Development.
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 merged 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 master or release line for which they are destined yet. For now, [Davide](https://github.com/dpvc) will be responsible for making all merged of Ready For Release issues into the MathJax repo.
......