From: Jani Nikula <jani.nikula@intel.com>
To: Lucas De Marchi <lucas.demarchi@intel.com>
Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>,
kernel test robot <yujie.liu@intel.com>,
intel-xe@lists.freedesktop.org, oe-kbuild-all@lists.linux.dev
Subject: Re: [Intel-xe] [drm-xe:oak/drm-evictable-lru 2911/3055] drivers/gpu/drm/i915/display/intel_display_power.h: linux/mutex.h is included more than once.
Date: Wed, 08 Nov 2023 19:37:30 +0200 [thread overview]
Message-ID: <875y2cxi1x.fsf@intel.com> (raw)
In-Reply-To: <i5hiabop2gm67f7yl4zvszqvtczoof3v55ikpt6k7i2ejmglut@reausbodh5kn>
On Wed, 08 Nov 2023, Lucas De Marchi <lucas.demarchi@intel.com> wrote:
> On Wed, Nov 08, 2023 at 12:02:17PM +0200, Jani Nikula wrote:
>>On Tue, 07 Nov 2023, Lucas De Marchi <lucas.demarchi@intel.com> wrote:
>>> On Tue, Nov 07, 2023 at 10:41:51AM +0200, Jani Nikula wrote:
>>>>On Tue, 07 Nov 2023, kernel test robot <yujie.liu@intel.com> wrote:
>>>>> tree: https://gitlab.freedesktop.org/drm/xe/kernel.git oak/drm-evictable-lru
>>>>
>>>>Why do we have this stale branch? I don't think developers should push
>>>>their branches to xe/kernel.git but their own repos instead.
>>>
>>> agreed. I just blocked branch creation in gitlab so we don't have
>>> those accidents anymore.
>>
>>I was looking for this yesterday. For future reference, which knob is it
>>and where in the gitlab UI?
>
> Settings > Repository > Protected branches
>
> - "drm-xe-next" [default] [protected]
> - Allowed to merge: Maintainers
> - Allowed to push and merge: Developers + Maintainers, Maintainers
>
> "*" (12 matching branches)
> - Allowed to push and merge: No one
> - Allowed to merge: No one
Right. I was close. I was looking at branch rules, and adding a branch
rule says, "To create a branch rule, you first need to create a
protected branch." but I didn't want to create a branch. Even under
protected branches it says, "Add protected branch", but I didn't want to
*add* branches, just prevent pushing. Oh well.
Thanks for doing this.
> I thought about creating a role to allow branch creation, but to keep it
> simple, I just blocked it. When/if we need it then we can temporarily
> disable the rule, like we do for force pushes when we rebase.
I'm not even sure you can add new roles in the free version.
BR,
Jani.
--
Jani Nikula, Intel
prev parent reply other threads:[~2023-11-08 17:37 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-11-07 2:39 [Intel-xe] [drm-xe:oak/drm-evictable-lru 2911/3055] drivers/gpu/drm/i915/display/intel_display_power.h: linux/mutex.h is included more than once kernel test robot
2023-11-07 8:41 ` Jani Nikula
2023-11-07 14:53 ` Zeng, Oak
2023-11-07 16:24 ` Lucas De Marchi
2023-11-08 10:02 ` Jani Nikula
2023-11-08 15:43 ` Lucas De Marchi
2023-11-08 17:37 ` Jani Nikula [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=875y2cxi1x.fsf@intel.com \
--to=jani.nikula@intel.com \
--cc=intel-xe@lists.freedesktop.org \
--cc=lucas.demarchi@intel.com \
--cc=oe-kbuild-all@lists.linux.dev \
--cc=rodrigo.vivi@intel.com \
--cc=yujie.liu@intel.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox