On Wed, 2021-01-13 at 15:57 -0600, Michael Catanzaro wrote: On Wed, Jan 13, 2021 at 9:28 pm, Philip Withnall <phi...@tecnocode.co.uk> wrote: > Given that you’ve just committed to submitting MRs and waiting for > CI > to pass, rather than pushing directly to master, perhaps this rule > should be rethought?
Hm... as long as we have permission to merge the MR after CI has passed, or to bypass the CI if it's broken due to a preexisting issue, then we should be good. However, I'm not sure GitLab allows this? E.g. we discovered yesterday that I didn't have permission to commit to gnome-remote-desktop until Jonas played with the settings; there, I had created a MR, but only project maintainers were able to merge it. I think, to do this you would effectively need to add the release team with Maintainer privileges to all projects (or, I suppose have a Release Team account for this purpose). I suppose that should be pretty simple to hook into the .doap synchronisation. Not sure how people people feel about having the Release team marked as a maintainer everywhere. Note that I am not really concerned about anyone merging a branch even if CI is failing without having a good reason to do so. Benjamin The worst-case scenario would be: need to revert a commit, CI is already broken due to some preexisting unrelated issue that we don't know how to fix, can't land revert via MR because it requires CI to pass, can't change the setting to allow bypassing CI because the only way to get permission to change the setting is to update the doap, can't update the doap without first passing CI.... _______________________________________________ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
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
