Re: Build sheriffs for GNOME

[Michael Catanzaro <mcatanzaro gnome org>]

Thank you Emmanuele, this will really help with keeping GNOME building.
I strongly support this change.

On Thu, 2016-01-21 at 14:54 +0000, Emmanuele Bassi wrote:
> This effort led to various benefits, including JHBuild not constantly
> being in a broken state, and most projects hosted on git.gnome.org
> finally building when builddir != srcdir, which should improve the
> ability of maintainers to do `make distcheck` on release days.

The next step is to convert either jhbuild or gnome-continuous to use
the others' modulesets. Currently the jhbuild modulesets are the
official "what we release," and they are more important because they
affect the ability of new contributors to build GNOME, so that's what I
focus on maintaining. Continuous is useful to catch many build
failures, but it misses many, many more failures than could only be
detected were it to use the official modulesets.

Continuous is a great first step (the response time is *stunningly*
good) and we're better off now that we have it, but it's not good
enough as it's not testing the build tool we use for development, it's
not testing what we release. We need to test that each module builds
with 'jhbuild build' with a completely empty install prefix, else
there's no way to find and fix the bajillions of dependency errors in
our modulesets. This is why new contributors say it is so hard to use
jhbuild, so hard to get started.

> What we need now, though, are "build sheriffs", i.e. people that
> watch
> the build process and ensure that it continues smoothly. Ideally,
> every maintainer would be on IRC, and would join the #testable
> channel; sadly, that's not the case.

Anecdote: Because Empathy uses a crummy notebook for tabs, opening more
rooms makes it much harder to switch between rooms and see which
important once have changes, hence I minimize the number of rooms I
join, hence I'm not going to join #testable as I am already in too many
rooms. I bet I'm not the only one. If anyone wants to fix Empathy to
have a saner view of rooms -- to use a sidebar like Polari, for example
-- I would be willing to join way more rooms.

>  Many are not even on
> #gnome-hackers, which means they miss the notification that the
> something broke the build.

Anecdote: I am on #gnome-hackers so you can ping me, but I don't turn
on notifications for every message in the room (too many!), so it's
rare that I notice a failure in one of my modules unless I happen to be
looking at #gnome-hackers at the time, or someone else pings me. It
would be really awesome if Continuous could learn to guess who to blame
for breakage and include the IRC name in the channel; I know it's hard
to decide who *actually* broke the build considering it could be due to
a change in a dependency, but even a dumb guess like the people in the
doap file for the broken project would be better than nothing, so at
least the maintainer knows and can investigate. (This would also be
incentive for past maintainers to remove their names from the doap
file. :)

It's not necessary -- Bugzilla works just as well, if slower -- but an
enhancement to consider if someone has time to spare to implement
it....

>   - if nothing happens for a reasonable amount of time (I'd give one
> to three hours)

I would support even less time: five minutes (if the maintainer cannot
be immediately contacted on IRC). Build breakage is a tremendous
obstacle to new contributors. In contrast, once I've found the problem
with a commit that got reverted, un-reverting it requires almost zero
effort. So if I'm not immediately available to look at my broken
commit, just revert it... no worries.


Michael