Re: Enabling builddir != srcdir by default in jhbuild

[Emmanuele Bassi <ebassi gmail com>]

Hi;

On 31 May 2016 at 16:01, Sébastien Wilmet <swilmet gnome org> wrote:
> On Mon, May 30, 2016 at 11:44:48PM +0100, Emmanuele Bassi wrote:
> > So, it seems that the discussion died on these shores.
> >
> > In the meantime, GVfs is but the latest module that broke because
> > people don't test under builddir != srcdir; I really, *really* don't
> > want to deal with this kind of perfectly avoidable build breakages any
> > more.
>
> The root of the problem, or the elephant in the room, is that committers
> push the commits directly on master.

No, not really.

I mean: in an idea world, we'd have code reviews for *every* commit,
and we'd have try servers; topic branches for bug fixes and features;
bots that deal with validating against a test suite every time a pull
request is updated; and bots that deal with merging to master. We'd
likely also have a build system that does not behave like it's 1983.

In reality, we make do with what we have.

> If you want real continuous
> integration/delivery, a commit should be pushed on master only if it has
> the green light from GNOME Continuous. It's the only way to avoid
> chasing continuously developers breaking stuff.

This is the role of a try server; the problem is that:

 a) we have many interacting components
 b) we don't have the resources to set up and maintain a try server
running continuous
 c) unless you have a very limited subset of developers being able to
push to master, people will push to master

I mean: we have an automated tool for translations that pushes to
master by default — and does not have any validation system to prevent
pushing translations breaking the build. We don't even have automated
hooks to validate translations, and those are usually the obvious
culprit of build failures.

A try server is not a simple thing to set up; and if the cost of
setting it up is non-negligible, it simply pales compared to the cost
of keeping it up. We can barely keep Continuous building as it is —
somebody would need to be funded full time just to keep it going for
each bug/feature/patch series that we'd want to test.

> There could be a master-next branch that GNOME Continuous test and
> rebase/merge on top of master automatically if the build and tests
> succeed.

It'll be a cold, cold day in hell before we can actually follow this
process with a system as complex as GNOME.

I mean: I proposed to have build sheriffs ensuring that Continuous
keep building and I nearly got accused of killing the GNOME community
because I had the temerity of saying that the subset of GNOME
specified in the Continuous manifest should always build, at the cost
of reverting commits that break the build if the maintainer is not
responsive.

> Would it be too cumbersome for committers?

Yes; but, more importantly, it would strain our existing
infrastructure way, way beyond any breaking point.

Ciao,
 Emmanuele.

-- 
https://www.bassi.io
[ ] ebassi [ gmail com]