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

[Bastien Nocera <hadess hadess net>]

On Wed, 2021-01-13 at 15:15 -0600, Michael Catanzaro wrote:
> 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.

I don't think you quite understand just how much trust was lost when a
member of the release team can't follow the goals we set ourselves as a
project.

You broke that trust, then bumbled into breaking it again, fixed the
code, but never actually cleaned up after yourself (see below).

There's no putting back together that broken trust. And I'm likely not
going to be able to trust the release-team's work until there's a
technical means to avoid the sort of breach of trust that just
happened.

There was nothing to deescalate, it was already too late.

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

You didn't need to. libgweather has NO API GUARANTEES. You should be
using tarballs or specific git commits for it.

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

libgweather still has no ABI/API guarantees.

> Other developers' work is blocked until GNOME is building again,

You could have pinned libgweather's version, as I keep saying.

>  so we 
> can't just wait for you to come online to sort things out.

You barely mentioned me on IRC during my evening. You didn't file
issues, you didn't file MRs that I could have reviewed or seen.

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


Maybe you should figure out what to do with libraries that have no API
or ABI guarantees of any sort that core modules rely on.

I tried to do my best pushing all the API and ABI breaking changes in a
single release to minimise breakage, and not have to come back to
modules to make changes _again_.

That took 3 full days of work. I'm sorry that broke your module, but
you had better options than do what we tell new contributors to not do
and commit directly to the main development branch.

libgweather still has no regression tests for the problem you fixed,
and the build log mentioned in the commit message will likely be
removed in a couple of weeks when we run out of storage.

And I'm not going to spend the time cleaning up after the release-team.

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

You know we can't restrict commits to the master branch, right?
Translations won't be able to be committed if we do that.

In any case, there's no point in further rehashing what happened. I'm
not going to work on libgweather until somebody does the work to allow
blocking commits to branches without breaking our translation tool, so
somebody should make sure that the work I mentioned gets done if you
want weather to still work in GNOME 40.