... | ... | @@ -135,7 +135,7 @@ As a result, the infamous MR (Merge Request) development model cannot be used di |
|
|
|
|
|
The MR development model works as follows:
|
|
|
- A restricted core development team is member of a project and has commit access to the development tree
|
|
|
- Some contributor starts contributing by forking the project ("fork" button). When hist contribution is ready, he opens a new merge request (in the "new" menu).
|
|
|
- Some contributor starts contributing by forking the project ("fork" button). When their contribution is ready, they open a new merge request (in the "new" menu).
|
|
|
- Someone from the core development team can then accept (or refuse) the Merge Request to be merged in the main development tree
|
|
|
|
|
|
This development model has several benefits:
|
... | ... | @@ -147,6 +147,6 @@ This development model has several benefits: |
|
|
So, here are some possible workarounds to this development model when using the Inria Gitlab with external contributors:
|
|
|
- Use pull-requests mechanisms at the git level, rather than at the Gitlab level. This is the way that the Linux kernel has been being developed for a long time now. Instead of submitting a MR with the Gitlab interface, contributors send patches by email.
|
|
|
- For projects with few known external contributors, it is possible that Inria members create forks on behalf of the external contributors, then transfer ownership of these forks to the contributors.
|
|
|
- For projects with few known and trusted external contributors, these contributors can be added to the project but develop in their own branches. But there is no mechanism at Gitlab level to ensure that they don't override their permissions.
|
|
|
- For projects with few known and trusted external contributors, these contributors can be added to the project but develop in their own branches. There are some basic mechanisms in Gitlab to ensure they don't override their permissions: if these users have role developer, they won't be allowed to push to protected branches (master, by default). Details on Gitlab permissions can be found here: https://gitlab.inria.fr/help/user/permissions.md.
|
|
|
|
|
|
If these workarounds do not fit well with what you need and you absolutely want to use the standard MR development model with external contributors, the only solution is to use another tool than the Inria Gitlab. |