GNOME.org
 

Re: Continuous Builds in GNOME

Hi Sri;

On 3 June 2016 at 02:53, Sriram Ramkrishna <sri ramkrishna me> wrote:

I found this discussion really fascinating and so I wanted to continue it,
separately from Emmanuele's thread so that issue is resolved without
bifurcating the discussion.

My thoughts are that we really shouldn't be looking at something and say
'well, we can't do it we don't have the resources' especially when there is
a clear return on investment.  I think this would be an interesting
challenge and we should find a way to figure out how we can attract the
talent, machines and money to do this.  After all, we have a foundation
dedicated to supporting the development of GNOME.


Can the Foundation hire a full time "build team" that:

 * keeps the build machines running
 * keeps the build running
 * works on the necessary tooling to integrate our Git repositories
activity with our mailing list, our bug tracking system, and possibly
our IRC channels

The current situation can barely run on volunteers time, and I think
it's time to be pretty clear on what our requirements are — instead of
architecture astronauting our way out.

We don't need machines; those are "easy" to get. We need actual people
that would fit the bill of a "devops" team; we need people that can
install and maintain a complex build system; that set up a Continuous
Integration process on top of our existing Continuous Delivery one;
and that can fill in the blank spots on the map between "this branch
on this module failed to build" and "this is breaking the whole GNOME
please fix it".

Right now, the easiest and cheapest option would literally be moving
the GNOME development infrastructure wholesale to GitHub, put
everything under Travis CI, and keep a separate machine somewhere that
cranks out GNOME Continuous images from the GitHub repositories. For
reasons that you may guess, this is not going to be a very good move.
Any other option involves replicating that set up on gnome.org
infrastructure, with all the issues that it entails.

Incidentally, if you find somebody like that, good luck not getting
them poached by companies that want the exact same thing, and are
likely to pay more than the GNOME Foundation for it.


We have an amazing infrastructure that we can attract possible very smart
people of whatever age to come and work on for the betterment of GNOME and
of course their own careers.


Colin Walters presented Continuous to the GNOME community in 2012 —
and it was already cranking out GNOME builds. Apart from a flurry of
activity in the beginning, I have not seen much interest being
attracted to the actual tools; for a long while, people didn't even
care much about the builds — and to be fair, why would they? It works
on *their* machine and maybe they can even release tarballs every once
in a while, and if it breaks patches welcome, right? Well, patches
started to arrive, and at the end we got a much better experience for
newcomers, with jhbuild not constantly breaking.

Still, people consider Continuous somebody else's problem; if it
"breaks on Continuous" but not on a maintainer machine, then who
cares?

Even if we magically got the resources (build machines, at least one
person working on the infrastructure side, volunteer work to improve
the tooling), the attitude of "my module is my fiefdom, if a build
breaks *you* fix it" has to change. GNOME has long since become an
interconnected, complex system, and it requires a level of oversight
that does not map with "a loosely coupled set of components", with
each one of them that may or may not build; may or may not pass tests;
may or may not break other components; may or may not lead to a
bootable, usable system.

So, more than a *technical* issue (as usual), this is a *social*
issue. People have to care about this stuff — and not just a couple of
people getting Continuous running.


I just hate when we say we don't have resources when we can't quantify what
we have and we aren't quantifying what we need.  I mean, yes, it is
difficult and hard right now, and so we need to make strategic plans to fix
it especially if it is a man power problem.  Our development, our
engagement, the board, everything is connected and so we need to look at it
from all angles.

I really love the ideas of try servers, and you know they have this some how
in github, and man, we should try to find clever means to do the same thing.


Sometimes there are no "clever" options, just the old dumb ones.

Ciao,
 Emmanuele.


---------- Forwarded message ---------
From: Emmanuele Bassi <ebassi gmail com>
Date: Tue, May 31, 2016 at 9:51 AM
Subject: Re: Enabling builddir != srcdir by default in jhbuild
To: Michael Catanzaro <mcatanzaro gnome org>
Cc: Desktop Development List <desktop-devel-list gnome org>


Hi;

I already pushed the default change to master, as that will only
affect new clones or updates. I'm also building locally the default
gnome moduleset — but I can safely say that the core platform builds
fine. I'm just worried about gnome-world, but for that I guess we'll
have to wait until stuff breaks.

Ciao,
 Emmanuele.

On 31 May 2016 at 17:47, Michael Catanzaro <mcatanzaro gnome org> wrote:

On Mon, 2016-05-30 at 23:44 +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.

Ciao,
 Emmanuele.


Emmanuele, I think you can feel free to change the default in jhbuild
provided that everything in the apps and core suites still builds after
doing so. i.e. you need to make sure to add exceptions in the jhbuild
modulesets for all modules that need it.

Just please wait a couple days first to see if there are any
substantial objections (which I do not expect).

Michael




--
https://www.bassi.io
[ ] ebassi [ gmail com]
_______________________________________________
desktop-devel-list mailing list
desktop-devel-list gnome org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

_______________________________________________
desktop-devel-list mailing list
desktop-devel-list gnome org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list




-- 
https://www.bassi.io
[ ] ebassi [ gmail com]
[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]