Fragmentation on the Linux Desktop (Is it Normal?) (Datamation) [LWN.net]

Fragmentation on the Linux Desktop (Is it Normal?) (Datamation)

Posted May 9, 2012 20:34 UTC (Wed) by ovitters (subscriber, #27950)
In reply to: Fragmentation on the Linux Desktop (Is it Normal?) (Datamation) by khim
Parent article: Fragmentation on the Linux Desktop (Is it Normal?) (Datamation)

Testing the latest version from git for GNOME means trying to get jhbuild to work. That is known to be painful. It can be suggested (if you figured out Bugzilla and where to file the bug, you're already an advanced user IMO), but not required.

You raise a few things where "release early, release often" doesn't work. But it is not really an argument not to still follow the "release early, release often".

Simplifying how to be able to try out a release is the goal. There are certain obstacles, some of which are really difficult to solve and might take a lot of time (talking about GNOME software). With time it hopefully becomes easier.

The small progress we're making is already by trying to release a live cd during GNOME unstable releases. Then other work is also underway (ostree). It is somewhat difficult as GNOME often requires changes other parts of the OS. So you cannot just provide a newer "gnome-boxes" without providing a newer "libosinfo" (it might not even be packaged), etc.

The work is done on different levels. GNOME Boxes is a really simple application to try out a live cd. Once that is in distributions, you can provide yet another (not perfect) option to try out the latest software.

(Log in to post comments)

Fragmentation on the Linux Desktop (Is it Normal?) (Datamation)

Posted May 10, 2012 8:53 UTC (Thu) by Company (guest, #57006) [Link]

There's one thing that we as GNOME botched completely, and that is working together with a distro (not distros, _a_ distro). I still see distros as the QA of a desktop effort (while upstream is the R&D part), and GNOME essentially does not have any QA at all. (To open parentheses a third time, this failure is also what lead to the GNOME OS effort - if we can't get distros to cooperate with us, we'll just do our own!)

What I'd have expected to happen long ago is that a distro provides a build farm that compiles per-commit packages that can be installed and used by anyone alongside the regular packages. I'd have expected these packages to work so seamlessly that they make jhbuild completely obsolete.
I'd also have expected the build farm of the distro to be a vital component of upstream development in that it is used to find build or test failures or even performance regressions and notifies the upstream developers of those, so they can be fixed in a timely fashion.
Last but not least I'd have expected the distro to cooperate with upstreams on the controlling and management effort - that is maintaining, analyzing and guiding bug tracking, proposed features and the overall user community.

All the distros do this to some extend, but they all do this in spite of upstreams, not with them. In particular the GNOME vs Ubuntu story is a good example of this. GNOME tries to do QA these days and fails as much as Ubuntu, which tries to develop code on its own. And worse off are all the people who have to use the resulting product(s).

Fragmentation on the Linux Desktop (Is it Normal?) (Datamation)

Posted May 10, 2012 14:37 UTC (Thu) by dgm (subscriber, #49227) [Link]

> GNOME tries to do QA these days and fails as much as Ubuntu, which tries to develop code on its own.

I don't get it. How is Ubuntu developing code a problem for GNOME? It doesn't seem to be a problem for XFCE, so why it is for GNOME?

I think that the notion that a distro is QA for upstream is at fault here. A distro should customize and configure, not fix. If they are forced to fix, then as easily they can write their own code. So, upstream needs its own QA. It's not acceptable to ship garbage and expect that users will pick up the pieces. You can ask for help, but if you rely on them giving it to you then you're doing it wrong.