Re: Build sheriffs for GNOME

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
    maintainers can be reachable within a 3 hour turnaround period.

    This leads me to believe that you fully expect to cause friction
    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
    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.


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