Re: Build sheriffs for GNOME

[Shaun McCance <shaunm gnome org>]

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

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
> 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
>
> _______________________________________________
> desktop-devel-list mailing list
> desktop-devel-list gnome org
> https://mail.gnome.org/mailman/listinfo/desktop-devel-list