[Mesa-dev] GitLab Migration: Users and Groups

Dylan Baker dylan at pnwbakers.com
Thu May 31 18:05:44 UTC 2018


We're moving to not force pushing stable branches anymore. The plan now is that
maintainers use some kind of "proposed" or "wip" branch that does have force
pushes, but that the (for example) 18.1 branch is *not* force pushed, and
anything that lands there but needs to be removed is reverted with a revert
commit.

Dylan

Quoting Stuart Young (2018-05-30 17:14:20)
> On 31 May 2018 at 02:15, Jason Ekstrand <jason at jlekstrand.net> wrote:
> 
>     Gitlab divides users into three categories per-project: Guests, Developers,
>     and Masters.  In general, developers and masters will have push access. 
>     Masters have the ability to add developers to the project.  Masters will
>     also have the ability to unlock the branch, force-push, and then re-lock if
>     needed.
> 
> 
> Just wondering if force-pushing like this would be necessary for people
> maintaining the stable branches? From what I gather this would probably be a
> rare event (and therefore one of the masters could do it on the maintainers
> behalf) but I'm not the one doing this sort of stuff on a day to day basis.
> 
> If so, then you'd need to add Dylan Baker to the list (for 18.1), and of course
> add each release maintainer as time goes on (unless they're already a master of
> course).
> 
> There is then also the issue of what happens when the branch stops being
> maintained (ie: going back to developer if not needed). Otherwise you might end
> up with more and more masters over time that are unnecessary.
> 
> Of course, as Ilia and Daniel mentioned, this would be good to be set out
> somewhere if this is the case, to avoid any confusion.
> 
> --
> Stuart Young (aka Cefiar)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 228 bytes
Desc: signature
URL: <https://lists.freedesktop.org/archives/mesa-dev/attachments/20180531/bf29fc9c/attachment-0001.sig>


More information about the mesa-dev mailing list