@@ -6,13 +6,13 @@ The steps below describe the process for contribution and integration of Change
#### 1. Contributor reserve a contribution name in the oneM2M portal
The contributor generates a new CR in the oneM2M portal so that a "contribution name" is generated.
The contributor generates a new CR in the oneM2M portal so that a **contribution name** is generated.
#### 2. Contributor creates a new branch for changes
The contributor creates a new branch for the contribution. See [Gitlab's branching documentation for more details](https://docs.gitlab.com/ee/user/project/repository/branches/).
The branch shall be based on the latest tag of the release candidate branch as start point.
The branch name shall reflect to "contribution name" generated by the oneM2M portal in the previous step.
The branch shall be based on the **latest tag of the release candidate branch** as start point.
The branch name shall reflect to **contribution name** generated by the oneM2M portal in the previous step.
#### 3. Contributor commits changes to the branch
...
...
@@ -27,16 +27,22 @@ A contribution can be composed of a set of commits or just one commit that inclu
#### 4. Contributor creates and submits a merge request
The contributor ensures that, once the contribution is ready, the contribution branch is locked (protected) and raises a Merge Request from the branch containing their changes named as the contribution branch.
The contributor, once the contribution is ready, raises a **Merge Request** from the branch containing their changes named as the contribution branch against the release candidate branch where the contribution branch was created from.
The submitted Merge Request shall include some description by filling the contribution template.
> Note: At this point of time, there are two coversheet contribution templates, a complete coversheet template and a simplified coversheet template. For the latter, the pipeline will use information taken from the **Merge Request**. Fields not present in the simplified template can be added and those will take priority against the information taken from the **Merge Request**.
The submission of the **Merge Request** will automatically lock the source contribution branch so that it cannot be modified anylonger.
#### 5. Contributor prepares and makes available a contribution on the ETSI Portal.
The contributor uploads the autogenerated CR to the oneM2M portal. This autogenerated CR contains the changes submitted, the contribution details as coverpage and a link to the new Merge Request.
The contributor uploads the autogenerated CR to the oneM2M portal. This autogenerated CR contains the changes submitted, the contribution details as coverpage and a link to the new **Merge Request**.
For example, Merge request CR1 proposes to merge branch "CR1" into branch Release-X (latest status which is tagged as X.Y.Z version).
> Note: The autogenerated CR should be reviewed before submitting it in order to verify its completeness.
For example, Merge request CR1 proposes to merge branch "CR1" into branch Release-X (latest status which is tagged as vX.Y.Z version).
#### 6. The usual contribution approval process of document is held leading to the approval of the contribution on the Portal (and minuted in the meeting report)
...
...
@@ -45,7 +51,9 @@ The rapporteur applies the Merge Request CR1.
In case of conflict, the rapporteur fixes the conflict by rebasing the contribution branch and/or fixing the conflict locally. <mark>The contribution needs to go to the normal approval process once again.</mark>
#### 7. The usual contribution approval process of document is held leading to revisions required – either due to email discussion , or discussion during a meeting
The Merge Request is renamed to CR1R01 (to reflect that it is being revised), and then the contribution branch is unlocked (unprotected) so that the contributor submits the required revisions. The contributor locks (protects) the contribution branch once the revision is ready. The autogenerated revised CR is submitted to the oneM2M portal. The process continues to step 6.
The **Merge Request** is renamed to CR1R01 (to reflect that it is being revised), and then the contribution branch is unlocked (unprotected) so that the contributor can submit the required revisions. Once the revision is ready (all necessary commits have been done to the contribution branch), the contributor runs a new pipeline for the **Merge Request**. The autogenerated revised CR is submitted to the oneM2M portal. The process continues to step 6.
> Note: Each pipeline run will make the contribution branch be locked again.
#### 8. The usual contribution approval process of document is held leading to the rejection of the contribution (and minuted in the meeting report)
...
...
@@ -53,4 +61,4 @@ The rapporteur closes the Merge Request CR1.
#### 9. Rapporteur produces a new baseline
The rapporteur creates a new tag on the branch Release-X to indicate a new baseline named X.A.B. A new baseline is autogenerated <mark> and the rapporteur uploads it to the portal.</mark>
In order to produce a new baseline, the rapporteur has to update first the release candidate branch (both history and version number)and then the rapporteur creates a new tag on the release candidate branch (i.e. Release-X) to indicate a new baseline named vX.A.B. A new baseline is autogenerated <mark> and the rapporteur uploads it to the portal.</mark>
