Re: GNOME Build situation and BuildStream

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

Hi Sasa,

On Tue, 2017-04-25 at 17:45 +0000, Sasa Ostrouska wrote:
> Woow, long one really. Ok, I think the idea is really good. Of course
> a lot of work. I as a maintainer of a gnome desktop version for
> Slackware would like to ask how this would handle the distros which
> do not use systemd ?

I did not expect this question, but I'm glad you asked it :)

Firstly, I can say that a new build tool is not going to magically make
GNOME work better on all distros, however it *can* help us to
understand the problem better and raise awareness, both for GNOME
developers and for distro developers/integrators.

Here's how I think we can greatly improve the integrator's experience:

> >   For CI
> >   ~~~~~~
[...]
> >   Further than this, I should mention there is some movement to implement
> >   Source plugins to represent distro packaging sources, e.g. the dpkg
> >   source plugin[4]. With this plugin in place, I suspect it will be
> >   very easy to run tests of building and running GNOME against various
> >   third party distributions and versions of those. Imagine we could have
> >   a board somewhere which displays which distributions GNOME builds on
> >   without failing tests (we could always know when GNOME master is failing
> >   against debian sid, or latest fedora, etc).

So, my vision of how we can improve communication and collaboration
between GNOME and it's consuming distros works something like this:

  o We would have a dedicated CI system which would build and hopefully
    run GNOME on a series of "subscribed" distros.

  o An interested party (distro representative/contibutor) would have
    to ensure that BuildStream have a 'Source' plugin which handles
    importing of distro packages in the package format which that
    distro uses.

    The requirements to meet for implementing a Source plugin are
    outlined in the comments of the 'dpkg source' issue[4].

  o The interested party then subscribes to the CI, by providing
    a simple patch to some YAML which says:

      - This is variant 'slackware'
      - This is how you obtain the 'slackware' base to build on
        (using the appropriate Source plugin to do the work).

    and then adding 'slackware' to a list of variants that the
    CI server should try building.

  o For every distro that passes some CI, a bootable image could
    be downloadable too, so one could easily try out the latest GNOME
    on a variety of bleeding edge versions of distros and compare the
    experience (this could be fun pretty quickly :))

I think it would be great if this CI was centralized and hosted by
GNOME in some way, even though I'm sure that most distros have their
own forms of CI, this would provide a venue for GNOME developers to
collaborate with distros directly and have a better understanding of
what kind of changes break distros in what ways.

Now of course in such a utopian future, it would be important to
understand that GNOME running CI against a variety of distros, does not
equate to GNOME making a promise to never break distros.

If a CI fails in this context then it could be for any of the following
reasons:

  o It is a legitimate integration bug in the distro
  o It is a legitimate bug somewhere in GNOME
  o The distro did not provide what GNOME requires
  o GNOME failed to communicate it's requirements clearly enough

So in closing, no this would not magically make GNOME easier to work
with when integrating on non-systemd distributions, at least not at
first.

However, it could help everyone understand the details and problems
surrounding integrating GNOME on any distro better, which would
contribute to a better experience for distro integrators in general
over time.

That is aside from the most obvious advantage, that building the
bleeding edge of GNOME against the bleeding edge of 'foo distro'
continuously will of course help everyone to catch integration bugs
earlier in the cycle.

Cheers,
    -Tristan

[4]: https://gitlab.com/BuildStream/buildstream/issues/10