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

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

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

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.


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