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

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:

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:

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.


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]