An important step in our development workflow is the testing of individual issues/tickets after the development on them is complete, and before the code is merges into the master branch. Developers pick one from the list of completed issues and perform a number of verification steps on it. The mechanics of testing a pull request (e.g. the git commands to use) are described here. This page is concerned with the aspects that should be considered in deciding whether a pull request should be recommended to merge or sent back to the developer for further work. There should be very little reluctance to reopen a ticket even for minor issues.
The code changes should be manually reviewed (the github compare view is ideal for this). A couple of pieces on the value of code review can be found at scientopia and codinghorror.
*.rst
file that has been added, containing an explanation of what exactly the algorithm does along with Python usage examples.The first thing to note is that this should not just be a quick check of whatever the ticket says it does. Testing should be as much, if not more, about making sure the code does not do what it’s not supposed to do as that it does do what it’s supposed to.
If all the requirements have been met and documented approve the PR using GitHub’s review mechanism.
The @mantidproject/gatekeepers
group is who is meant to merge pull requests into master. This is done by social contract. A gatekeeper can merge
code if: