Re: Reminder: action required when updating dependencies or build options
- From: Bastien Nocera <hadess hadess net>
- To: Benjamin Berg <benjamin sipsolutions net>, Michael Catanzaro <mcatanzaro gnome org>, philip tecnocode co uk
- Cc: desktop-devel-list gnome org
- Subject: Re: Reminder: action required when updating dependencies or build options
- Date: Thu, 14 Jan 2021 12:06:00 +0100
On Thu, 2021-01-14 at 11:57 +0100, Benjamin Berg wrote:
On Wed, 2021-01-13 at 15:57 -0600, Michael Catanzaro wrote:
On Wed, Jan 13, 2021 at 9:28 pm, Philip Withnall
<philip 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.
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...
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....
Or file issue, pin version of broken module in your build scripts, wait
until maintainer is available to fix everything.
Or create a branch (and an MR) and point your build scripts at the
branch.
Or ask the sysadmins to verify the module's permissions.
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]