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 <ja...@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)
signature.asc
Description: signature
_______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
