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
signature.asc
Description: This is a digitally signed message part
_______________________________________________ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
