Re: Build sheriffs for GNOME

[Michael Catanzaro <mcatanzaro gnome org>]

On Fri, 2016-01-22 at 16:03 +0900, Tristan Van Berkom wrote:
>   o We are a volunteer driven project with contributors distributed
>     across timezones, who have dayjobs, it is ridiculous to expect
> that
>     maintainers can be reachable within a 3 hour turnaround period.
>
>     This leads me to believe that you fully expect to cause friction
> by
>     reverting commits before said maintainers have the time to even
>     respond, and doing so on the unstable master branch.
>
>     The master branch should ideally not be littered with reverts and
>     reverts of reverts, it is the main history of project development
>     and adding such noise to master should be avoided as much as
>     possible for the purpose of preserving the integrity and value of
>     the history.

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 breakage
is ever acceptable. If your code is not buildable at all times in
Continuous, keep it on a *side branch* -- otherwise, tag your module in
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 branched
and tagged, master needs to build. This isn't the wild west.


>     My interpretation of your proposal is that you would want to
> revert
>     this api break or behavioral change if it were found to break the
>     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 only
>     correct solution is to have applications adapt to the new API or
>     behavior before the next stable release.

It's a big problem that some modules break for days or weeks at a time
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. We need to land these transitions
better, by ensuring either that they occur in side branches, where all
modules' side branches are merged into master at the same time, or else
by tagging the relevant modules in Continuous and branching them in
jhbuild until the transition is completed.

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

Michael