| |||||||||||||
actually getting buildsactually getting buildsPosted Sep 26, 2013 1:47 UTC (Thu) by torquay (guest, #92428)In reply to: actually getting builds by mattdm Parent article: GNOME 3.10 Released
It would be safe to say there would be far more testers for Gnome 3.10 if it was easier to install it on existing distributions, rather than putting it out there as part of a mud-ball of updates (ie. next distro release). The only people who'd test it at the moment are those with enough time and patience to build it from source, which is to say a relatively small set. Parallel installation with an existing Gnome would be the ultimate solution, though I do understand that might be a lot of effort. However, is there anything technically that's preventing such a solution?
(Log in to post comments)
actually getting builds Posted Sep 26, 2013 2:04 UTC (Thu) by torquay (guest, #92428) [Link] follow up: while ebassi and mcatanzaro point out below that there are VM images and a live USB, I'm not sure such approaches can replace testing that comes from more than taking a quick test drive. Having the next release parallel installable with the previous release would allow people to test things out more thoroughly, and switch back when they encounter a "this breaks my stuff" problem.
actually getting builds Posted Sep 26, 2013 14:32 UTC (Thu) by walters (subscriber, #7396) [Link] That is exactly is the goal of the OSTree project; it allows clean parallel installation of multiple versions of multiple independent operating systems, without hacking around at the block layer with partitions or btrfs snapshots. There are people working on integrating Debian packages, Arch packages, and yum/rpm with it now. There's still a lot to do for this, but I think once it's ready it will have a dramatic impact on the end user experience with Free Software development streams.
actually getting builds Posted Sep 26, 2013 10:22 UTC (Thu) by ebassi (subscriber, #54855) [Link] GNOME is deeply integrated with your system, and during every release cycle the system integration gets updated as well to provide the features that we depend on. if you don't mind compiling, then you can use JHBuild to build the entire GNOME moduleset, which is what the release team does whenever they announce a new release of GNOME, as well as what GNOME developers use to actually develop GNOME. this works relatively well for most of the system, but when system dependencies are involved, it breaks down pretty much immediately; yes, you can do feature negotiation, but that doesn't help you if you want to check out the system integration, or hardware-related features, or if the system dependencies change API and are not parallel installable *cough* BlueZ *cough*. GNOME as a whole is not in the distro business: we sure as hell are not making our own distro, and we try as much as we can to avoid carrying distro-specific hacks; the whole push to use standardised DBus interfaces to talk to the system is to avoid the mess that was the previous system, which relied on ad hoc Perl script that did distro-specific discovery. also, the resources are what they are, so we cannot create an upgradable live image for every distro out there. the Fedora live image comes from Fedora; we used to have an OpenSUSE live image that was created by OpenSUSE people. any effort to create we do have OSTree, which allows for parallel installable, updatable operating system trees, and which is used to do continuous integration; you cannot install it on bare metal (we don't want to ship firmware, hardware-specific drivers, or security updates) but you can easily test it in a virtual machine. you can use the Boxes application, which makes using and testing virtual machine images really easy. so, as you can see, there are various ways to get the latest and greatest of GNOME without requiring you to wait for your distribution to update; there are technical reasons why we can't provide you with a reliable parallel installable GNOME-next blob, and those are all pretty much tied to the fact that we're fixing the lower level issues and adding features there, instead of papering over differences with abstraction layers.
actually getting builds Posted Sep 26, 2013 18:21 UTC (Thu) by mathstuf (subscriber, #69389) [Link]
Don't forget that if 3.10 updates your config files, you might be stuck there. It's not just parallel binaries you want, but save/restore on your configuration files.
actually getting builds Posted Sep 26, 2013 19:34 UTC (Thu) by hummassa (subscriber, #307) [Link]
Better an alternate config files directory, no? This was an issue in the kde3-4 transition also...
actually getting builds Posted Sep 26, 2013 20:14 UTC (Thu) by mathstuf (subscriber, #69389) [Link]
Possibly, but then 3.10 needs to know to look at 3.9's directory, 3.8's, 3.7's, etc. Maybe GNOME could use a "Trial session" mode where it stores all of the config changes in another place and then asks "commit/abandon" on logout?
actually getting builds Posted Sep 26, 2013 20:46 UTC (Thu) by khim (subscriber, #9252) [Link] Or even simpler: Canary build (like Chrome is doing). It can be parallel-installed and you can test stuff when it's developing, but it does not affect your regular life at all. I really miss Chrome Canary on Linux, hope they'll add it at some point.
actually getting builds Posted Sep 26, 2013 22:15 UTC (Thu) by hummassa (subscriber, #307) [Link]
chrome-dev, chrome-beta and chrome-regular on linux can run side-by-side (different config directories)... but their deb packages conflict with one another, so you have to make some magic to install all of them...
|
|||||||||||||