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