commit f26e4bc58d80717f2d8893a9f72003cfc84da014 Author: juga0 juga@riseup.net Date: Fri Jun 26 07:42:33 2020 +0000
fix: doc: Replace Github review process to Gitlab
Replace also Github terminology to Gitlab. --- docs/source/contributing.rst | 57 +++++++++++++++++++++++++++----------------- 1 file changed, 35 insertions(+), 22 deletions(-)
diff --git a/docs/source/contributing.rst b/docs/source/contributing.rst index 161f971..658cf80 100644 --- a/docs/source/contributing.rst +++ b/docs/source/contributing.rst @@ -24,8 +24,9 @@ Code/documentation patches ---------------------------
The sbws canonical repository is https://gitweb.torproject.org/sbws.git, -but we review patches using the Github canonical repository -(https://github.com/torproject/sbws) Pull Requests (PR). +but we review patches using the Gitlab repository +(https://gitlab.torproject.org/tpo/network-health/sbws/-/merge_requests) +Merge Requests (MR).
To know more about ``sbws`` code,
@@ -39,12 +40,12 @@ To know more about ``sbws`` code,
The following are guidelines we aim to follow.
-Steps to create a PR +Steps to create a MR ~~~~~~~~~~~~~~~~~~~~~
1. Create a issue in Tor Project Gitlab (:ref:`Open issue <ticket-ref>`) -2. Clone ``sbws`` via the Github web interface - https://github.com/torproject/sbws +2. Fork ``sbws`` via the Gitlab web interface: + https://gitlab.torproject.org/tpo/network-health/sbws 3. Clone the repository locally 4. Install ``sbws`` as explained in ./INSTALL.rst and ./TESTING.rst Use ``pip install -e <>`` @@ -56,11 +57,23 @@ Steps to create a PR 7. Write code (:ref:`codestyle-ref`), tests, documentation, extra files (:ref:`extrafiles-ref`), commit (:ref:`commits-ref`), etc. 8. Ensure tests pass (./TESTING.rst). -9. Push your branch to your repository. If you have an account in Travis, - you can see whether it pass the tests in Github and in - https://travis-ci.org/youruser/sbws/ -10. Create a PR from your branch to https://github.com/torproject/sbws -11. Change the Trac ticket status to ``needs_review`` +9. Push your branch to your Gitlab repository. + +We are temporally using Github Travis to ensure tests pass. For this: + +10. Clone ``sbws`` via the Github web interface: + https://github.com/torproject/sbws +11. Push your branch to your Github repository. + +12. If you have an account in Travis, you can see whether it pass the tests in + Github and at https://travis-ci.org/youruser/sbws/ + +Finally: + +13. Create a MR from your branch at + https://gitlab.torproject.org/tpo/network-health/sbws + +
.. _codestyle-ref:
@@ -154,27 +167,27 @@ Template originally written by `Tim Pope`_: :ref:`example commit <commit-msg>` Code being reviewed workflow ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-When a PR is being reviewed, new changes might be needed: +When a MR is being reviewed, new changes might be needed:
- If the change does not modify a previous change, create new commits and push. - If the change modifies a previous change and it's small, `git commit fixup https://git-scm.com/docs/git-commit#Documentation/git-commit.txt---fixupltcommitgt`_ - should be used. When it is agreed that the PR is ready, create a new branch + should be used. When it is agreed that the MR is ready, create a new branch named ``mybranch_02`` and run:
.. code-block:: bash
rebase --autosquash
- push, create new PR and close old PR mentioning the number of the new PR. -- If the review takes long and when it's ready code related to the PR has changed + push, create new MR and close old MR mentioning the number of the new MR. +- If the review takes long and when it's ready code related to the MR has changed in master, create a new branch named ``mybranch_02`` and run:
.. code-block:: bash
rebase master
- push, create new PR and close old PR mentioning the number of the new PR. + push, create new MR and close old MR mentioning the number of the new MR.
[MERG]_
@@ -196,23 +209,23 @@ Reviewers: - Should let the contributor know what to improve/change. - Should not push code to the contributor's branch. - Should wait for contributor's changes or feedback after changes are requested, - before merging or closing a PR. -- Should merge (not rebase) the PR. + before merging or closing a MR. +- Should merge (not rebase) the MR. - If rebase is needed due to changes in master, the contributor should create a new branch named `xxx_rebased` based on the reviewed branch, rebase and - create a new PR from it, as explained above. + create a new MR from it, as explained above. - If new changes are needed when the contributor's branch is ready to merge, the reviewer can create a new branch based on the contributor's branch, - push the changes and merge that PR. + push the changes and merge that MR. The contributor should be notified about it. -- If the reviewer realize that new changes are needed after the PR has been +- If the reviewer realize that new changes are needed after the MR has been merged, the reviewer can push to master, notifying the contributor about the changes. - Because currently there are not many reviewers, reviewers can merge their own - PR if there was not any feedback after a week. + MR if there was not any feedback after a week. - Should not push directly to master, unless changes are trivial (typos, extra spaces, etc.) -- Should not push to master new features while there are open PRs to review. +- Should not push to master new features while there are open MRs to review.
Currently, the reviewers are the persons that have contributed to the code: pastly, teor, juga.