... | ... | @@ -131,12 +131,12 @@ This Inria Gitlab instance offers accounts both to Inria members (who login usin |
|
|
|
|
|
This limitation for external users has an important result: from the Gitlab point of view, forking a project *is* creating a project, thus external users cannot fork projects.
|
|
|
|
|
|
As a result, the infamous MR (Merge Request) development model cannot be used directly with external users, but some workarounds can be used in some situations.
|
|
|
As a result, the well-known MR (Merge Request) development model cannot be used directly with external users, but some workarounds can be used in some situations.
|
|
|
|
|
|
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 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
|
|
|
- Someone from the core development team can then accept (or refuse) the Merge Request to be merged into the main development tree
|
|
|
|
|
|
This development model has several benefits:
|
|
|
- It limits the access to the main development tree to a small group of trusted core developers.
|
... | ... | @@ -145,8 +145,8 @@ This development model has several benefits: |
|
|
- With tools such as Github or Gitlab, the web user interface for merge requests is very user friendly.
|
|
|
|
|
|
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.
|
|
|
- Use pull-requests mechanisms at the git level, rather than at the Gitlab level. This is the way that the Linux kernel has been 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 for Inria members to 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. 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. |