Re: Build sheriffs for GNOME

[Milan Crha <mcrha redhat com>]

On Fri, 2016-01-22 at 16:03 +0900, Tristan Van Berkom wrote:
> In summary, I am not opposed to applying your proposal as is to the
> stable builds, there is no justification *ever* for breakage in stable
> branches.
>
> For master, I only think this needs to be detailed properly, perhaps it
> would be enough to ensure we had policy ensuring that intentional
> breakage is announced (on this list ?) and that "sheriffs" are
> responsible for following this list and not reverting commits which
> break things intentionally in a transitional period.

        Hi,
I agree with Tristan. I was just about to write something along his
lines. Seeing semi-automated reverts in the projects would be quite
depressing, especially when the semi-automat has no idea about the
project and what the change was meant for.

It makes sense to make sure the build works *before the release*, but
when we are in the middle of two releases, then the build break might
be just a red flag, not an excuse to break someone's work by the
revert.

I sometimes find it hard to plan some larger work due to too often
releases (it's for a really large work, which can take several weeks to
accomplish, then some more to fine tune in the real world usage). If
you add this precedence, to always let someone ask: "oh, well, can I
commit it? It's large, would anyone revert it? My change touches API
and influences like 5+ projects, where I have only 3 under my direct
control, thus the main commit is almost immediately followed by
corresponding fixes in those projects I've under control, but some
still can be broken", then I'm afraid the "hostile environment" would
be a very nice word about GNOME and its infrastructure (people would
use much much worse in the case you'd really make your proposal alive).

This is also about different environments, you partly mentioned it. I
believe most of the maintainers build before commit. I do, but I'm a
human and mistakes happen. Some mistakes are independent of the build
environment (I'm sorry for the before-Christmas breakage of the eds),
some are not. I recall broken builds even in jhbuild when API changes
happened (clean build was required to make it work, there was nothing
wrong about the sources).

Even for example Ubuntu environment is different from that I use,
causing undefined symbols on places which work just fine for me. What
would you revert then in my project? I know, Continuous, it built an
hour earlier, it should build now too.

Anyway, doing any reverts might not be implicit, not without a previous
discussion with the respective maintainers (unless they are not
reachable), and only a day before the release - or on the Friday when
the notification mail is sent, though for Weekend Contributors it would
make more sense for Monday morning of the release day? I do not know,
people can fix things just before the release too. It's because the
GNOME should build from the release, not necessarily from the git
snapshot.

The Continuous idea is great to discover build breaks early, but it's
not an excuse to damage anyone's work.
        Bye,
        Milan