Re: Build sheriffs for GNOME

On Fri, 2016-01-22 at 16:03 +0900, Tristan Van Berkom wrote:
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
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
the offending modules, if they are hosted on GNOME infrastructure,
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
recognize a module maintainer's word as scripture. As such we do not
commit changes to others modules without expressed permission unless
is for a minor change that we are absolutely sure about.

It has always been my understanding that master (née trunk née HEAD) is
supposed to be buildable in GNOME, and that the release team has the
power to make commits to ensure it is.

I am sympathetic to the difficulty of synchronizing cross-module API
changes. But is there any reason those changes can't all be done in
development branches in each module, with all of them merged to master
at the same time when they're ready?

 There is/was a
page describing this policy to those who receive commit access
explaining the responsibility that comes with being a committer, it
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
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
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
    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 think this is unfriendly at best and I would prescribe a one
    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

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

For master, I only think this needs to be detailed properly, perhaps
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.


desktop-devel-list mailing list
desktop-devel-list gnome org

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