[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]
[tor-commits] [sbws/maint-1.1] fix: doc: Replace Github review process to Gitlab
commit f26e4bc58d80717f2d8893a9f72003cfc84da014
Author: juga0 <juga@xxxxxxxxxx>
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.
_______________________________________________
tor-commits mailing list
tor-commits@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-commits