Re: Build sheriffs for GNOME

[Tristan Van Berkom <tristan upstairslabs com>]

On Thu, 2016-01-21 at 14:54 +0000, Emmanuele Bassi wrote:
[...]
> This is not enough, and it does not raise the bar in keeping GNOME in
> a buildable state. It actually lowers it a fair , to the effective
> point that *nobody* cares about Continuous builds.
>
> I want this to change. I want to be able to revert failing commits on
> the offending modules, if they are hosted on GNOME infrastructure, if
> they fail for more than N hours, and *then* open a bug about it.

Hi Emmanuele,

In GNOME, we have got along well for many years with many projects
sharing the same infrastructure mostly because we find that in
practice, people are generally respectful enough of eachothers work to
recognize a module maintainer's word as scripture. As such we do not
commit changes to others modules without expressed permission unless it
is for a minor change that we are absolutely sure about. There is/was a
page describing this policy to those who receive commit access
explaining the responsibility that comes with being a committer, it has
either gone missing or I cannot currently find the text.

In that context, I admit that I first interpreted your proposal as
hostile, at least in it's current form, because it violates this policy
which has allowed our projects to exist in harmony for so many years
under the GNOME umbrella, by awarding some kind of revert power to an
arbitrary group of individuals. I can see much opportunity here for
unnecessary dispute, if special care is not taken, we may risk
incentivizing maintainers to host their projects elsewhere.

On the other hand, it is desirable to have things building regularly,
of course the master branch is inherently unstable - that's what it's
for, but I would however support your proposal without hesitation were
it to be applied to stable branches only.

Were we to apply your proposed policy to master, I think we need
further thought and clarification before carrying that out:

  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 think this is unfriendly at best and I would prescribe a one week
    period for master. We should really wait for the maintainers word
    before intruding and reverting commits which introduce breakages
    which may have even been intentional.


  o Not all libraries advertize API/ABI stability, especially when it
    comes to libraries whos only consumers are GNOME applications, we
    allow ourselves much more leniency here than with platform
    libraries which are also relevant outside of the GNOME ecosystem.

    During the course of unstable development, it is entirely common
    for a library to introduce a new API and then to later change it,
    even more than once before it is ready for a stable release.
    For instance, EDS's backend facing APIs are not stable, and there
    have been regular issues in the vala API it exposes and libfolks
    consumes.

    There are periods where it must be accepted that things are just
    broken in a transitional phase.

    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.

In summary, I am not opposed to applying your proposal as is to the
stable builds, there is no justification *ever* for breakage in stable
branches.

For master, I only think this needs to be detailed properly, perhaps it
would be enough to ensure we had policy ensuring that intentional
breakage is announced (on this list ?) and that "sheriffs" are
responsible for following this list and not reverting commits which
break things intentionally in a transitional period.

Regards,
    -Tristan