Re: Build sheriffs for GNOME

[Michael Catanzaro <mcatanzaro gnome org>]

On Fri, 2016-01-22 at 10:55 +0100, Milan Crha wrote:
>       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.

Why does it matter what the change was meant for? If people cannot
build GNOME, that is a much more serious problem than whatever your
commit is fixing.

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

Let's take e-d-s as a specific example. If we were building tarball
releases of e-d-s in jhbuild and Continuous, this would make perfect
sense. We're not doing that. We build e-d-s from git master because it
is a core component of GNOME, and we want jhbuild to build the latest
version of everything, and we want contributors to be able to
contribute to e-d-s after all!, hence the need for a git repo. master
needs to be buildable at all times. This isn't for you, it's for
*everyone else* trying to build GNOME.

Now, you could choose to work around this if you want, by tagging e-d-s 
in Continuous and branching it in jhbuild, then updating that branch
with every release. Or, you could work in a "next" branch that gets
merged into master each release. Personally, I would continue to work
in master, and accept that once in a while a change of mine will get
reverted until I have figured out what is wrong with it....

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

Milan, you have full commit access to every repo on git.gnome.org. Any
breakage that could register on Continuous is fully within your ability
to fix.

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

Yeah, we don't expect incremental builds to always work. There's just
no way to make that possible. We do expect clean builds to work.

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

The value of Continuous is that it is a neutral environment. I'd like
to set up additional jhbuild builders to do CI in Ubuntu, Fedora, Arch,
etc. so that we can catch build breakage in more environments.

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

Milan, I honestly feel that you might be better off using a "next"
branch if you really don't want any commits to be reverted. (That might
be the compromise solution here.) Or change jhbuild and gnome-
continuous to build your stable branch instead.

Michael