Re: Build sheriffs for GNOME

On Fri, 2016-01-22 at 10:37 -0600, Michael Catanzaro wrote:
I really don't think it's a big deal to have a few reverts in the git
history. And anyway, reverts should be relatively rare, because build
breakage should be relatively rare.

The master branch may be unstable, but that doesn't mean build
is ever acceptable. If your code is not buildable at all times in
Continuous, keep it on a *side branch* -- otherwise, tag your module
Continuous, branch it in jhbuild, and do whatever you want in master.
But as long as you have an official GNOME module, if it's not
and tagged, master needs to build. This isn't the wild west.

Of course, when you commit something and your *own* code does not
compile, this is a very, very rare thing, rare enough to not be worth
discussion I think, it that's happening, it's a problem.

But it's common enough with many moving parts that the breakage is
indeed intentional, in which case screwing with the history is only

    My interpretation of your proposal is that you would want to
    this api break or behavioral change if it were found to break
    build (or the tests) of another module, during this unstable
    development period.

    This would obviously be wrong and would just be an obstacle to
    progress in the cases where breakage is intentional and the
    correct solution is to have applications adapt to the new API
    behavior before the next stable release.

It's a big problem that some modules break for days or weeks at a
during API transitions; this makes it very difficult for new
contributors to build and run GNOME, and it's inconvenient for
experienced contributors as well.

This kind of breakage is just a fact of life, you cannot sweep it under
the rug and pretend it does not exist.

Sure, it's a barrier of entry for newcomers and an annoyance for
experienced developers who realize the facts of life. But that's just
the way it is, there is no reason to complain about it.

Software development is difficult, integration is difficult when you
have many moving parts that are in a development stage before being
release ready.

To be clear: if you've branched and tagged your module, then you do
whatever you want in master without hurting anyone else. But
master needs to be buildable.

And to be doubly clear: the master branch is *not* what is advertised
by upstream maintainers as stable, it is the bleeding edge, it can have
churn, it may not always match up to other modules perfectly, other
modules may have not yet adapted to the churn. Building master may be
asking for trouble, again, this is just a fact of life if you are
trying to integrate with all bleeding edge component in the middle of
their development cycle, instead of what maintainers have published as

If you want something that you are sure will build, take the stable
release tag and build that.


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