Re: Reminder: action required when updating dependencies or build options

[Philip Withnall <philip tecnocode co uk>]

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.
>
> 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....

I don’t know anything about what the release team is doing with all
these modules, or why, but perhaps rather than the default being “pull
in all the modules into an OS build and urgently push fixes to the
modules if something fails”, could the default be “only pull module
updates into an OS build if they don’t fail”? i.e. Essentially pinning
each module in the OS build by default, and regularly updating those
pins via a CI gate.

Then individual module maintainers can work at their own pace, and
updates (e.g. API changes) can land in different modules without
needing prior consultation with the release team.

I might be wide off the mark since I don’t know the problem space. Just
carping from the sidelines.

Philip