| |||||||||||||
Fragmentation on the Linux Desktop (Is it Normal?) (Datamation)Fragmentation on the Linux Desktop (Is it Normal?) (Datamation)Posted May 9, 2012 11:34 UTC (Wed) by khim (subscriber, #9252)In reply to: Fragmentation on the Linux Desktop (Is it Normal?) (Datamation) by ovitters Parent article: Fragmentation on the Linux Desktop (Is it Normal?) (Datamation)
If distributions lag behind upstream, then upstream will have less feedback and development will be slower. You're going against the "release early, release often" basically. Does it really matter? Developers usually don't want to talk about distro-supplied options anyway, they ask you to test latest version from git. This is where the whole thing falls apart: typical user of server-side software can build and test top-of-the-tree software: server-side software tend to be simpler (or at least more self-contained) and users are more computer-savvy. Typical user of Linux desktop can not do this (many of them are completely lost when they need to use command line, for example). This breaks "release early, release often" cycle completely: feedback from actual users can only be received when it's way too late to change anything.
(Log in to post comments)
Fragmentation on the Linux Desktop (Is it Normal?) (Datamation) Posted May 9, 2012 20:34 UTC (Wed) by ovitters (subscriber, #27950) [Link]
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.
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.
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.
|
|||||||||||||