Re: Reminder: action required when updating dependencies or build options



On Thu, 2021-01-14 at 12:21 +0100, Bastien Nocera wrote:
On Thu, 2021-01-14 at 12:08 +0100, Benjamin Berg wrote:
On Thu, 2021-01-14 at 12:06 +0100, Bastien Nocera wrote:
This is likely a migration problem, as the project was originally
in
Jonas' personal namespace, right? All the projects under the
GNOME
namespace should have the same settings allowing anyone in the
project to commit anything and merge anywhere, for better or for
worse...

Not quite. Everyone listed in the .doap file is a "Maintainer",
while
everyone else is a "Developer". So you can just change the
protection
o
the master branch to only allow everyone in the "Maintainer" group
to
merge. This will prevent everyone who is not listed in the .doap
file
from merging.

I know that screen well. I'm saying that the settings were likely in
that position because the module was migrated from a personal
namespace. That's not how modules are setup by default in the GNOME
namespace.

(Or Jonas changed them, obviously :)

Yeah, hadn't quite read it properly.

But, that in turn isn't really compatible with the idea that the
Relase
Team is the one who should always be able to handle emergencies in
case
a maintainer is not available at the time. So, they kind of need to
have the Maintainer permissions in order to always be able to step
in,
even if projects have configured branch protections.

There are many ways to workaround or fix this (as mentioned in my
previous email) without allowing implicitly or explicitly the release
team to commit directly to the main development branches, so I don't
see why we would need to make an exception for that case.

Everyone seems to agree that it is not a good idea to just bypass CI.
And, it seems like Michael already said that he intends to change his
workflow and use MRs.

To me, it still seems completely reasonable for the release team to
have some extra powers. Using them does mean stepping into the
territory of maintainers, but I think we should be accepting of the
occasional mistake and annoying fallout that this may cause. After all,
being accepting of it will hopefully result in a better work experience
for everyone.

Benjamin

Attachment: signature.asc
Description: This is a digitally signed message part



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