Re: GNOME Build situation and BuildStream

[Sasa Ostrouska <casaxa gmail com>]

On Wed, Apr 26, 2017 at 8:51 AM, Tristan Van Berkom <tristan vanberkom codethink co uk> wrote:

Hi Sasa,

Hi Tristan !
 

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 :)

I want just to clarify that I do not intend change this discussion about if use or not use systemd and

personally i have nothing against it, its just that the distro i use do not supply it. I think similar situation

is with *BSD .

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.

Correct, I would personally like to see it be easier buildable on my distro. But there are some things

which Slackware does not have and on some parts of gnome it is a dependency. In some cases I can

add this to Slackware and I do it for many years already. But in cases of an init system is a bit difficult

because it requires too much low level changes. Therefore the idea of minimum and well defined dependencies

is really good in my opinion.

 

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.

This is ok with me, and I am ready to pick it up. Especially for doing the needed

packages.

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

Ok will take a look at it.
 

  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.

Perfect, seems fine to me.
 

  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 :))

Yep, thats good.
 

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.

Agreed.
 

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.

Correct.
 

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.

Yeah, my intendion with the init system question was mostly to understand on how you plan to handle this ?

I can try to push up some people in Slackware community who could help up to get the desired deps up

to date.

Gnome already works quite fine without systemd, some troubles are with gdm , but other things mostly work

out up to 3.20 which i use right now. I will try to step up and build also 3.24 in the near future, but I am afraid

much things will no longer work due to systemd requirement.

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

Rgds

Saxa