Re: Build sheriffs for GNOME

[Tristan Van Berkom <tristan upstairslabs com>]

On Fri, 2016-01-22 at 12:12 -0500, Shaun McCance wrote:
> 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.

And it has always been my understanding that it is simply not the case,
notably because of said cross module API changes.

It annoys me that in recent years, notably after the introduction of
jhbuild, which has saved us a lot of trouble of setting up local
environment scripts and building everything by hand, that this
expectation has somehow arisen, this expectation is just causing
friction, it simply cannot be expected within reason.

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

Yes.

Here is one example:

Michael Catanzaro writes in this very thread:
> Milan, you have full commit access to every repo on git.gnome.org.
> Any breakage that could register on Continuous is fully within your 
> ability to fix.

I find this statement very disconcerting, and it relates and is a good
example.

Milan maintains EDS, and EDS is a relatively *huge* and complex source
base, I personally know Milan to be considerate about API breakages and
stability in general and I trust that if he has to change the API
contract, it is in the interest of long term maintainability of this
very complex project which has gone though a *lot* of churn over the
last decade.

Milan does not maintain libfolks, and he does not maintain gnome-
contacts, if he is going to spend weeks refactoring EDS and Evolution,
I am not going to tell him that his word is not the law, his word on
the EDS contract *is* law, and I'm confident that he will announce it,
and that maintainers of related modules will have a heads up with
enough time to adjust for the next stable GNOME release.

I am not going to tell Milan that hey, I know you spent weeks or months
of your life refactoring and making EDS better, but I will not accept
that you land your work in your own module unless you spend another
week modifying libfolks and/or gnome-contacts.

Changes like this need to be introduced as soon as they are ready in
master, which is the unstable development branch until the next stable
release is made. It cannot be delayed until the maintainer of libfolks
returns from vacation and wraps his head around the new changes, then
we lose time and we cause friction with other patches landing in
master, accumulating conflicts and generating more work - this work is
not necessary, because nobody every guaranteed that "all of GNOME
master" would build harmoniously together at a given time.

Here is another example, Benjemin Otte one week or two ago landed some
huge refactoring in GTK+ related to drawing - as a result, Glade is
entirely unusable. It's entirely possible that I may have had an
installable unit test in Glade to raise a flag on this.

Are you, really, going to go and revert the landing of his branch
because the unit test flagged GTK+ as broken ?

Sure, for a single project which builds regularly against a stable
platform, the expectation is always that master builds. But this
analogy of a single project cannot not carry on to GNOME, which is an
assembly of distinctly separately run projects which are developed
under the same infrastructure, integration issues will obviously arise
and the best that we can hope for is introducing those issues as early
as possible in the cycle and try our best to stabilize by the end of
the cycle, when churn comes to a halt and individual modules stabilize.

Best Regards,
    -Tristan