Re: Build sheriffs for GNOME

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

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

Milan, you have full commit access to every repo on 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
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
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

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.


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