Re: [ Revised Proposal ] Continuous Builds in GNOME

[Tristan Van Berkom <tristan vanberkom codethink co uk>]

Hi Philip,

On Tue, 2016-06-21 at 04:28 +0000, philip chimento gmail com wrote:
[...]
> Tristan, I wonder if I can present a different perspective that might
> reconcile these differences.
>
> I'm an active contributor to the gtk-osx module, which is a
> collection of scripts and jhbuild modulesets for building (some of)
> the GNOME stack on Mac OSX. While I personally believe very much in
> the goal of the GNOME desktop as a unified platform, I also put a lot
> of work into keeping the the GNOME stack libraries buildable on Mac,
> so that people can provide builds of GNOME apps (such as Gedit) on
> Mac as well as build their own cross-platform apps using GNOME tools.
> I think you even reviewed some of my patches to make Glade buildable
> on Mac not too long ago.
>
> I hope you'll agree that this is a diverse use of GNOME modules,
> focused on consumers outside of the GNOME desktop.

Sure,

Running GNOME apps built on the GNOME stack on other operating systems
qualifies, and helps to raise our standards of quality and flexibility;
at least ensuring that some of our apps and libraries arent tied too
tightly to 'linux only' or even 'linux + systemd only'. But I'm also
interested in seeing our stack being the stack of choice for developing
appliances and systems in the IVI and mobile spaces for instance. It
was not all that long ago that GTK+ was a viable competitor to Qt for
embedded.

>  Please believe me then when I say that _nothing_ would make me more
> happy, in the capacity of gtk-osx contributor, than a CI system, and
> with it the ability to assume that the entire stack is buildable at
> any given time.

Yes, some things would make us happy even if they are not entirely
viable, and this is the point I've been trying to make.

The _only_ way this can be even halfway viable is if we were to make
the statement that all projects under the GNOME umbrella have the
single priority of integrating into a single unified user experience
and that this goal should override all other technical considerations -
this is a statement I perceive as hostile towards projects which only
want to be the best solution for the functionalities they provide. And
the people who just want to work on the best solution, are the people
we should be trying to attract and engage.

That said, there are two types of build breakages, there are simple
mistakes and there are intentional API breakages, I dont even want to
talk about mistakes, apparently there are many of those and that should
stop, if we want to be industry leaders; please dont go committing
stuff that breaks even the build of your own module.

Regarding intentional breakages; while I personally would love it if
the whole platform were to be meticulously API and ABI stable at all
times this is just not possible. Firstly, we don't hold all platform
libraries to the high standards as we do glib for instance, and
secondly; in order to improve the platform we need to refactor
vigorously. If we cannot enforce a discipline where all API breaks come
with an entirely new, parallel installable library (not soname bump),
then this refactoring will equate to API breaks, and if we're not
making them, then we are stagnating and falling behind.

If you've been following planet GNOME you will be aware that in fact
the GTK+ team is considering a plan to break API more often; with a
rolling 'unstable' release; if this route is taken then you can expect
a lot more cross-module breakages, how can one expect that all of GNOME
projects 'master' branch always be in sync with API changes from
underlying modules ? The best we can do is introduce breakages early in
the cycle, allowing a reasonable grace period for depending projects to
adapt to those.

On the other hand, having a reference 'integration' branch which always
does build, or a 'master-stable' as Sébastien has called it (it's
pretty much the same proposal when you boil it down), would allow us to
always easily see the delta of what modules have adapted to API
changes, and would also provide an entry point for newcomers to have
something as close to master as possible which builds.

Anyway, at this point I'm just reiterating the same things I've been
saying since our first thread in January - and for doing so I am
perceived as the enemy of CI, I am not; I just dont see how everything
'master' can possibly be expected to always be buildable, and trying to
come up with some approach which could.

Cheers,
    -Tristan