Re: Protected branches in GNOME's GitLab

2018-04-30 Thread Carlos Soriano
A small correction from Florian's asnwer:

We had a period that some branches were protected by default because I
didn't know how to deactivate that. But it shouldn't be the case for new
projects or new migrated projects.

Cheers

On 30 April 2018 at 19:19, Florian Müllner  wrote:

> On Mon, Apr 30, 2018 at 6:30 PM Milan Crha  wrote:
>
> > Does it mean, that an automatically created user in GNOME's GitLab
> > instance, basically a complete stranger, receives the Developer
> > privilege, even when it's a Reporter (in bugzilla terms)?
>
> No. In the GNOME group, only people with GNOME git access have Developer
> privilege (that is, everyone who is allowed to push to git.gnome.org). If
> anyone else wants to contribute changes, they have to fork the project in
> their personal namespace. As they have full ownership of their fork (Master
> privilege), they can push all the changes they want however they see fit
> (but without affecting the original upstream repository of course).
>
> Only when they want their changes to be applied back upstream they open a
> merge request (from some branch in their forked repository to a branch
> (likely master) in the original repo), and someone with Developer privilege
> can then review those changes and merge them once they are happy with the
> result.
>
>
> > Which branches are marked as protected in GNOME's GitLab? The master
> > branch is probably protected by default. Which are the other branches?
>
> None as far as I know.
>
>
> > According to [1] I can mark/unmark branches as protected when I'm at
> > least the Master level of the project, but doing that each six months
> > when branching for stable feels like one more thing to easily forget
> > about, thus it would be nice to have some common "mark-as-protected
> > gnome-X-YZ branches when created"
>
> You can protect multiple branches with a single rule by using a wildcard,
> for example "gnome-*" (to catch all current and future stable branches) or
> "gnome-3-*" (to make unintended matches less likely).
>
> Cheers,
> Florian
> ___
> desktop-devel-list mailing list
> desktop-devel-list@gnome.org
> https://mail.gnome.org/mailman/listinfo/desktop-devel-list
>
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Protected branches in GNOME's GitLab

2018-04-30 Thread Florian Müllner
On Mon, Apr 30, 2018 at 6:30 PM Milan Crha  wrote:

> Does it mean, that an automatically created user in GNOME's GitLab
> instance, basically a complete stranger, receives the Developer
> privilege, even when it's a Reporter (in bugzilla terms)?

No. In the GNOME group, only people with GNOME git access have Developer
privilege (that is, everyone who is allowed to push to git.gnome.org). If
anyone else wants to contribute changes, they have to fork the project in
their personal namespace. As they have full ownership of their fork (Master
privilege), they can push all the changes they want however they see fit
(but without affecting the original upstream repository of course).

Only when they want their changes to be applied back upstream they open a
merge request (from some branch in their forked repository to a branch
(likely master) in the original repo), and someone with Developer privilege
can then review those changes and merge them once they are happy with the
result.


> Which branches are marked as protected in GNOME's GitLab? The master
> branch is probably protected by default. Which are the other branches?

None as far as I know.


> According to [1] I can mark/unmark branches as protected when I'm at
> least the Master level of the project, but doing that each six months
> when branching for stable feels like one more thing to easily forget
> about, thus it would be nice to have some common "mark-as-protected
> gnome-X-YZ branches when created"

You can protect multiple branches with a single rule by using a wildcard,
for example "gnome-*" (to catch all current and future stable branches) or
"gnome-3-*" (to make unintended matches less likely).

Cheers,
Florian
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list


Protected branches in GNOME's GitLab

2018-04-30 Thread Milan Crha
Hello,
this might be a lame question, but this time I tried to read the
documentation first. I hope I didn't miss anything related to my
question. If I did, then I apologize.

When one wants to propose a change, aka create a merge request, in
GNOME GitLab instance, then it can be done only on a writable checkout
of the related project, which makes sense and is expected. It's similar
as requesting the person to create a bugzilla account to send patches,
thus it's fine. I also came through [1], where is written that the
lowest possible member level to create merge requests is a Developer.

Does it mean, that an automatically created user in GNOME's GitLab
instance, basically a complete stranger, receives the Developer
privilege, even when it's a Reporter (in bugzilla terms)?

Which branches are marked as protected in GNOME's GitLab? The master
branch is probably protected by default. Which are the other branches?
I definitely do not want to see a complete stranger modify stable
branches.

According to [1] I can mark/unmark branches as protected when I'm at
least the Master level of the project, but doing that each six months
when branching for stable feels like one more thing to easily forget
about, thus it would be nice to have some common "mark-as-protected
gnome-X-YZ branches when created", maybe on the same hook which sends
the messages to gnome-doc and such lists when the project creates the
stable branch, like in case of the most recent gnome-3.28. You've it
probably already there, I only do not know where to look for it,
neither I think I'd have access to it.

Thanks and bye,
Milan

[1] https://docs.gitlab.com/ce/user/permissions.html
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list