On Wed, Apr 26, 2017 at 8:51 AM, Tristan Van Berkom < [email protected]> 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
_______________________________________________ desktop-devel-list mailing list [email protected] https://mail.gnome.org/mailman/listinfo/desktop-devel-list
