From 3329e8737b2f1c590a9339f1af67df90f7d717e0 Mon Sep 17 00:00:00 2001 From: Natale Patriciello Date: Mon, 17 Dec 2018 11:31:19 +0100 Subject: [PATCH] doc: finished last things --- CONTRIBUTING.md | 5 ++--- doc/manual/source/working-with-git.rst | 2 +- 2 files changed, 3 insertions(+), 4 deletions(-) diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md index 7dbffc5f2..db70750e3 100644 --- a/CONTRIBUTING.md +++ b/CONTRIBUTING.md @@ -153,9 +153,8 @@ The process described here has several goals: Please follow these steps to have your contribution considered by the maintainers: -1. Follow all instructions in [the template](doc/MERGE_REQUEST_TEMPLATE.md) -2. Follow the [styleguides](#styleguides) -3. After you submit your merge request, verify that all status checks are passing
What if the status checks are failing?If a status check is failing, and you believe that the failure is unrelated to your change, please leave a comment on the merge request explaining why you believe the failure is unrelated. A maintainer will re-run the status check for you. If we conclude that the failure was a false positive, then we will open an issue to track that problem with our status check suite.
+1. Follow the [styleguides](#styleguides) +2. After you submit your merge request, verify that all status checks are passing
What if the status checks are failing?If a status check is failing, and you believe that the failure is unrelated to your change, please leave a comment on the merge request explaining why you believe the failure is unrelated. A maintainer will re-run the status check for you. If we conclude that the failure was a false positive, then we will open an issue to track that problem with our status check suite.
While the prerequisites above must be satisfied prior to having your merge request reviewed, the reviewer(s) may ask you to complete additional design work, tests, or other changes before your pull request can be ultimately accepted. diff --git a/doc/manual/source/working-with-git.rst b/doc/manual/source/working-with-git.rst index 30c098e3d..53c95fd61 100644 --- a/doc/manual/source/working-with-git.rst +++ b/doc/manual/source/working-with-git.rst @@ -54,7 +54,7 @@ Assume that you are the user *john* on GitLab.com and that you want to create a #. Navigate to https://gitlab.com/nsnam/ns-3-dev #. In the top-right corner of the page, click ``Fork``. -Note that you may only do this once; if you try to fork again, Gitlab will take you to the page of the original fork. So, if you are planning to maintain two or more separate forks (for example, one for your private work, another for maintenance, etc.), you are doing a mistake. Instead, you should add these forks as a remote of your existing directory (see below for adding remotes). +Note that you may only do this once; if you try to fork again, Gitlab will take you to the page of the original fork. So, if you are planning to maintain two or more separate forks (for example, one for your private work, another for maintenance, etc.), you are doing a mistake. Instead, you should add these forks as a remote of your existing directory (see below for adding remotes). Usually, it is a good thing to add the maintainer's repository as remotes, because it can happen that "bleeding edge" features will appear there before landing in ns-3. For more information on forking with Gilab, there is plenty of visual documentation (https://docs.gitlab.com/ee/gitlab-basics/fork-project.html). To work with your forked repository, you have two way: one is a clean clone while the other is meant to re-use an existing ns-3 git repository.