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

[Michael Catanzaro <mcatanzaro gnome org>]

On Thu, Jan 14, 2021 at 11:04 am, Bastien Nocera <hadess hadess net> 
wrote:
> 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.

Well you're certainly right about one thing: I definitely do not 
understand. I already promised to use merge requests from now on before 
you started this discussion on-list. And it's not like we're swooping 
in changing random things in your project. The only situation where 
release team is going to commit to your project without asking you 
first is when something fails to build. That's it. If you don't like 
what we do, you can simply revert it. (I won't mind, as long as you 
don't again break the build.) Commits are free, after all. So yeah, 
this seems like much ado about nothing to me.

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

You never asked us to do this. I cannot read your mind. We don't pin 
other unstable libraries (like gnome-desktop, for example), and there 
are many advantages to not doing so. But if this is what you want, we 
can do it.

Since you're no longer interested in contributing to libgweather, I'm 
going to keep building it from git master. If you change your mind, 
then we can switch it to build from tarball. That said, there are 
disadvantages to doing this. We won't update the tarball for you. Other 
GNOME apps will be responsible for ensuring they don't use anything 
newer than what's available in the pinned tarball. And distros will 
probably update to the newest available tarball anyway, diverging from 
what we have in GNOME.

> >  Other developers' work is blocked until GNOME is building again,
>
> You could have pinned libgweather's version, as I keep saying.

We try hard to avoid it whenever possible, because experience indicates 
that pinning too many tarballs can quickly get out of hand. But we can 
do this if you request it.

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

I pinged you immediately in #gnome-hackers. You were just not online at 
the time. That's fine; you can hardly be expected to be present 
precisely when I notice an issue!

Filing issues doesn't make sense when there is a build failure, because 
we need to fix it immediately, without waiting around for maintainers 
to assess the situation. Reporting an issue makes more sense if 
something needs to be done *after* the build is fixed. In the case of 
libgweather, no further action was required after I fixed your broken 
gobject-introspection.

I've promised to file MRs from now on, but you'll only have a chance to 
review them if you notice immediately. If you're not OK with this, go 
into gnome-build-meta and change your modules to be built from tarball, 
or ask us to do so for you.

Waiting for maintainers does not scale at all because we build dozens 
upon dozens of interconnected components and often have many build 
failures all at the same time. It could take several days to get a 
successful build if we had to wait for every affected maintainer to 
grant permission to fix things.

Michael