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

[Michael Catanzaro <mcatanzaro gnome org>]

On Wed, Jan 13, 2021 at 7:53 pm, Bastien Nocera <hadess hadess net> 
wrote:
> "I need to remember not to [push commits directly to the main branch]
> for your modules, sorry"

I was trying to be sincere, not dismissive:

mcatanzaro: "I need to remember not to for your modules, sorry"
"Can hardly complain about people not following dependency rules when I 
can't remember simple things like this myself"

After that discussion, I then proceeded to land a broken commit in 
gnome-calendar, at which point I no longer had a leg to stand on. 
That's when I said I would use MRs for all modules, not only yours:

https://gitlab.gnome.org/GNOME/gnome-calendar/-/merge_requests/156

It's a little more work, but you're right that it's a good idea and 
best-practice. I had hoped that concession would deescalate this 
situation. Clearly not.

> It was still needed. There were 8 modules that needed to have their
> compatibility checked, for which I filed individual issues.
>
> The vapi fix wasn't going to be enough to fix the other 7 modules, 
and
> waiting for those fixes to roll in could have happened in a branch 
for
> gnome-build-meta, with that module's CI making sure that all the 
ducks
> were in a row, and each fix actually peer-reviewed (or at least CI
> checked).

Bastien, how could I know about any of this?

If you wanted to do a planned transition, you could have told us in 
advance so we could coordinate on how to do it. We might have created a 
libgweather compatibility element with the old API version, for 
example, and switched dependencies to use that ahead of time. Instead, 
you got an uncoordinated emergency response where you had no control 
over the resolution. Fortunately, Calendar was the only core app that 
required changes.

Other developers' work is blocked until GNOME is building again, so we 
can't just wait for you to come online to sort things out. This delayed 
a WebKit update, for example. Nowadays GNOME consists of hundreds of 
interconnected components, and we can't afford to have fiefdoms when 
the build is broken.

> This isn't what made me drop libgweather. This was the last straw. 
What
> started it was this commit which you pushed directly to the main
> branch, and claimed that building was broken for weeks. It was broken
> for a couple of hours:
> 
https://gitlab.gnome.org/GNOME/grilo-plugins/-/commit/4329dda2c53f9a7bd2a3f6dd9334d4eb5207e9fd

I don't remember what happened four years ago, sorry. I assume that 
jhbuild was broken, otherwise that would probably not have drawn my 
attention.

> And similar behaviour over the years where you seemed to be under the
> impression that I was the only person in GNOME that felt that peer-
> reviewed patches and CI-gated merge requests were a requirement.
>
> Until the main development branch is protected and it's not possible 
to
> push directly there, I don't see myself being interested in
> contributing to modules where I filled the maintainer gap.

This is disappointing. If you restrict commits, please let release team 
know, because we have a rule that we only build modules from git master 
if we can commit to them to fix build failures. We would just need to 
switch your modules to build from tarball instead. Building core 
software from tarball instead of git would reduce the value of GNOME OS 
and the master runtime for everyone, but it is an option.

Michael