gpsd-dev
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [gpsd-dev] Request for commit access (gpsd)


From: Sanjeev Gupta
Subject: Re: [gpsd-dev] Request for commit access (gpsd)
Date: Sun, 2 Jun 2019 02:47:16 +0800

Eric, thank you, I got a notification from Gitlab, too.  I promise not to drink and push.

However, there is still an issue.  The master branch is protected, and he old settings (I assume when the project was created on Gitlab) were that only Owners and Maintainers can push or merge to a protected branch.  Since then, Gitlab has introduced a finer access control, you have a choice of:
  1. Owners and Maintainers can push or merge
  2. Owners and Maintainers can push or merge, Developers cannot push directly, but can accept merges
I believe the second should be what we use, else the bottleneck remains.

From: https://docs.gitlab.com/ee/user/project/protected_branches.html

Since GitLab 8.11, we added another layer of branch protection which provides more granular management of protected branches. The “Developers can push” option was replaced by an “Allowed to push” setting which can be set to allow/prohibit Maintainers and/or Developers to push to a protected branch.

Using the “Allowed to push” and “Allowed to merge” settings, you can control the actions that different roles can perform with the protected branch. For example, you could set “Allowed to push” to “No one”, and “Allowed to merge” to “Developers + Maintainers”, to require everyone to submit a merge request for changes going into the protected branch. This is compatible with workflows like the GitLab workflow.

However, there are workflows where that is not needed, and only protecting from force pushes and branch removal is useful. For those workflows, you can allow everyone with write access to push to a protected branch by setting “Allowed to push” to “Developers + Maintainers”.

You can set the “Allowed to push” and “Allowed to merge” options while creating a protected branch or afterwards by selecting the option you want from the dropdown list in the “Already protected” area.

I believe we should use the workflow in the second paragraph, ie: Developers can NOT push directly to master, but can fork, push to Gitlab,create a merge request, and then merge into master.

See also: https://stackoverflow.com/a/53936520 for the screenshot (although Gitlab keeps changing its UI).

Thanks
--
Sanjeev Gupta
+65 98551208     http://www.linkedin.com/in/ghane


On Sun, Jun 2, 2019 at 2:26 AM Eric S. Raymond <address@hidden> wrote:
Sanjeev Gupta <address@hidden>:
> As it would help to fix one set of issues, push, regenerate pages, and
> repeat, may I request commit access?  Promise not to touch the code till I
> learn python or C :-)
>
> Gary has been very helpful, but I think that I will be cluttering history
> with 'git rebase'  due to the async between me making MRs, and seeing them
> appear in git head.  Having commit access will prevent this.

I just upgraded your access to "Developer".  Thanks for all the good
work you've done - it might nit seem like we notice, but we do.
--
                <a href="" href="http://www.catb.org/~esr/" rel="noreferrer" target="_blank">http://www.catb.org/~esr/">Eric S. Raymond</a>



reply via email to

[Prev in Thread] Current Thread [Next in Thread]