GitLab is used only for code review, issue tracking and project management. Canonical locations for source code are still https://gitweb.torproject.org/ https://git.torproject.org/ and git-rw.torproject.org.

Commit 88a8c220 authored by Georg Koppen's avatar Georg Koppen

Merge branch 'maint-1.1' into master

parents ffd6e86d b9f92100
......@@ -3,8 +3,11 @@
The following people have contributed to Simple Bandwidth Scanner.
Thank you for helping make Tor better.
* juga0
* anadahz
* George Kadianakis
* Georg Koppen
* juga
* Matt Traudt
* teor
*Last updated: 2018-09-14 on 27766cc*
*Last updated: 2020-06-26 on d7a822bf*
......@@ -36,8 +36,8 @@ destination IP closer to the scanner exit.
scanner setup
----------------------
Install sbws according to `<INSTALL.rst>`_ (in the local directory or GitHub)
or `<INSTALL.html>`_ (local build or Read the Docs).
Install sbws according to `<INSTALL.rst>`_ (in the local directory or Tor
Project Gitlab) or `<INSTALL.html>`_ (local build or Read the Docs).
To run the ``scanner`` it is mandatory to create a configuration file with at
least one ``destination``.
......@@ -57,12 +57,12 @@ If ``sbws`` is installed from the sources as a non-root user then create the
configuration file in ``~/.sbws.ini``.
More details about the configuration file can be found in
``./docs/source/man_sbws.ini.rst`` (in the local directory or GitHub) or
`<man_sbws.ini.html>`_ (local build or Read the Docs) or
``./docs/source/man_sbws.ini.rst`` (in the local directory or Tor Project
Gitlab) or `<man_sbws.ini.html>`_ (local build or Read the Docs) or
``man sbws.ini`` (system package).
See also ``./docs/source/man_sbws.rst`` (in the local directory or GitHub) or
`<man_sbws.html>`_ (local build or Read the Docs) or ``man sbws`` (system
package).
See also ``./docs/source/man_sbws.rst`` (in the local directory or Tor Project
Gitlab) or `<man_sbws.html>`_ (local build or Read the Docs) or ``man sbws``
(system package).
.. _Content delivery network: https://en.wikipedia.org/wiki/Content_delivery_network
......@@ -76,7 +76,7 @@ Configuration and deployment
``sbws`` needs :term:`destination` s to request files from.
Please, see `<DEPLOY.rst>`_ (in the local directory or GitHub) or
Please, see `<DEPLOY.rst>`_ (in the local directory or Tor Project Gitlab) or
`<DEPLOY.html>`_ (local build or Read the Docs)
to configure, deploy and run ``sbws``.
......
......@@ -23,8 +23,8 @@ of the Tor bandwidth authorities, to avoid creating unnecessary traffic.
**ADVICE**: It is recommended to read this documentation at
[Read the Docs](https://sbws.rtfd.io). In
[Github](https://github.com/torproject/sbws) some links won't be properly
rendered.
[Tor Project Gitlab](https://gitlab.torproject.org/tpo/network-health/sbws)
(tpo Gitlab) some links won't be properly rendered.
It can also be read after installing the Debian package ``sbws-doc`` in
``/usr/share/doc/sbws`` or after building it locally as explained in
``./docs/source/documenting.rst``.
......@@ -33,19 +33,19 @@ It can also be read after installing the Debian package ``sbws-doc`` in
Installing
------------
See [./INSTALL.rst](INSTALL.rst) (in local directory or GitHub) or
See [./INSTALL.rst](INSTALL.rst) (in local directory or tpo Gitlab) or
[INSTALL.html](INSTALL.html) (local build or Read the Docs).
Deploying and running
---------------------
See [./DEPLOY.rst](DEPLOY.rst) (in local directory or GitHub) or
See [./DEPLOY.rst](DEPLOY.rst) (in local directory or tpo Gitlab) or
[DEPLOY.html](DEPLOY.html) (local build or Read the Docs).
Changelog
--------------
See [./CHANGELOG.rst](CHANGELOG.rst) (in local directory or GitHub) or
See [./CHANGELOG.rst](CHANGELOG.rst) (in local directory or tpo Gitlab) or
[CHANGELOG.html](CHANGELOG.html) (local build or Read the Docs).
Documentation
......@@ -66,5 +66,5 @@ software in ./LICENSE.md
## Authors
See [./AUTHORS.md](AUTHORS.md) (in local directory or GitHub) or
[AUTHORS.html](AUTHORS.html) (local build or Read the Docs).
\ No newline at end of file
See [./AUTHORS.md](AUTHORS.md) (in local directory or tpo Gitlab) or
[AUTHORS.html](AUTHORS.html) (local build or Read the Docs).
......@@ -17,16 +17,16 @@ Bug reports or feature requests
.. _ticket-ref:
* Open a ticket in
`Tor Project Trac <https://trac.torproject.org>`_
and assign the component to ``Core Tor``/``sbws``.
* Open a issue in
`Tor Project Gitlab <https://gitlab.torproject.org/tpo/network-health/sbws/-/issues>`_ .
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,
......@@ -40,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 ticket in Tor Project Trac (:ref:`Open ticket <ticket-ref>`)
2. Clone ``sbws`` via the Github web interface
https://github.com/torproject/sbws
1. Create a issue in Tor Project Gitlab (:ref:`Open issue <ticket-ref>`)
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 <>``
......@@ -57,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:
......@@ -133,7 +145,7 @@ but not all.
Commits
~~~~~~~~~
Each commit should reference the Tor Project Trac ticket (example: ``#12345``)
Each commit should reference the Tor Project Gitlab issue (example: ``#12345``)
and possibly the bugfix version.
The commit message should contain ``Closes: #bugnumber``.
......@@ -168,27 +180,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]_
......@@ -210,26 +222,27 @@ 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.
Currently, the reviewers are `gk <https://gitlab.torproject.org/gk>`_,
`ahf <https://gitlab.torproject.org/ahf>`_,
`juga <https://gitlab.torproject.org/juga>`_.
.. _releases-ref:
......@@ -268,7 +281,7 @@ Before major releases, ensure that:
.. _changelog:
Create a ./CHANGELOG.rst file.
Each entry should reference the Tor Project Trac ticket (example: ``#12345``)
Each entry should reference the Tor Project Gitlab issue (example: ``#12345``)
and possibly the bugfix version.
Until version 1.0.2 we have followed `keep a changelog`_ format.
......
......@@ -226,4 +226,4 @@ SEE ALSO
BUGS
----
Please report bugs at https://trac.torproject.org/.
\ No newline at end of file
Please report bugs at https://gitlab.torproject.org/tpo/network-health/sbws/-/issues/.
......@@ -114,4 +114,4 @@ https://gitweb.torproject.org/torspec.git/tree/bandwidth-file-spec.txt,
BUGS
----
Please report bugs at https://trac.torproject.org/.
\ No newline at end of file
Please report bugs at https://gitlab.torproject.org/tpo/network-health/sbws/-/issues/.
......@@ -18,7 +18,7 @@ To appear in Tor v0.4.1.x:
bandwidth-file-digest sha256=01234567890123456789abcdefghijkl
https://trac.torproject.org/projects/tor/ticket/26698
https://gitlab.torproject.org/tpo/core/tor/-/issues/26698
Directory authorities' bandwidth file URL
-----------------------------------------
......@@ -29,4 +29,4 @@ To appear in Tor v0.4.1.x:
/tor/status-vote/next/bandwidth.z
https://trac.torproject.org/projects/tor/ticket/21377
https://gitlab.torproject.org/tpo/core/tor/-/issues/21377
......@@ -43,7 +43,9 @@ rd = None
controller = None
FILLUP_TICKET_MSG = """Something went wrong.
Please create a ticket in https://trac.torproject.org with this traceback."""
Please create an issue at
https://gitlab.torproject.org/tpo/network-health/sbws/-/issues with this
traceback."""
def stop_threads(signal, frame, exit_code=0):
......
......@@ -1250,7 +1250,7 @@ class V3BWFile(object):
# Generators SHOULD NOT limit measured bandwidths based on
# descriptors' bandwidth-observed, because that penalises new
# relays.
# See https://trac.torproject.org/projects/tor/ticket/8494
# See https://gitlab.torproject.org/tpo/core/tor/-/issues/8494
# If the observed bandwidth is None, it is not possible to
# calculate the minimum with the other descriptors.
# Only in this case, take the consensus bandwidth.
......
Markdown is supported
0% or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment