Skip to content
Snippets Groups Projects
Commit a44fdc06 authored by Miguel Angel Reina Ortega's avatar Miguel Angel Reina Ortega
Browse files

Adding contribution process text

parent f7e4f709
No related branches found
No related tags found
No related merge requests found
## Contributions process to specs
### Overview of the process
The steps below describe the process for contribution and integration of Change Requests using GitLab repositories.
#### 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.
#### 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 status 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
The contributor makes a set of changes (either modifications or additions) to the newly-created branch.
This activity can be executed in several ways:
* Via the web interface of Gitlab (either the "Edit" button or the "Web IDE")
* Via Git (by using a Git client locally)
A contribution can be composed of a set of commits or just one commit that includes all desired changes.
#### 3. 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 submitted Merge Request shall include some description by filling the contribution template.
#### 4. 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.
For example, Merge request XYZ proposes to merge branch "XYZ" into branch Release-X (latest status which should be tagged as X.Y.Z version).
#### 5. 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)
The rapporteur applies the Merge Request XYZ.
In case of conflict, the rapporteur fixes the conflict by rebasing the contribution branch and/or fixing the conflict locally. The contribution needs to go to the normal approval process once again.
#### 6. 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
XYZR1 (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 5.
#### 7. The usual contribution approval process of document is held leading to the rejection of the contribution (and minuted in the meeting report)
The rapporteur closes the Merge Request XYZ.
#### 8. Rapporteur produces a new baseline
The rapporteur creates a new tag on the branch Release-X to indicate a new baseline named X.Y.Z. A new baseline is autogenerated and the rapporteur uploads it to the portal.
0% Loading or .
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment