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
Jonas' personal namespace, right? All the projects under the
namespace should have the same settings allowing anyone in the
project to commit anything and merge anywhere, for better or for

Not quite. Everyone listed in the .doap file is a "Maintainer",
everyone else is a "Developer". So you can just change the
the master branch to only allow everyone in the "Maintainer" group
merge. This will prevent everyone who is not listed in the .doap
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

(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
Team is the one who should always be able to handle emergencies in
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
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.


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]