I just had a discussion with Owen about the state of F14+gnome-shell, and wanted to give an update on why we decided not to try updating it from the current state (last updated Jul 13), and concentrate on F15 instead.
So most of the development has been happening in git/jhbuild, and we haven't even managed to get rawhide updated due to the XULRunner changes (work on rawhide is proceeding now, https://bugzilla.gnome.org/show_bug.cgi?id=622896 for the curious).
Now, multiple things would need to occur for F14: - Separate clutter 1.4 parallel install package Impact on critical path: None. Sort of ugly is the only thing.
- Updated GTK3 package Impact on critical path: Low/None (some things in F14 oddly require gtk3 that shouldn't, like seed...needs investigation). But we'd *also* have to look at either updating packages like gnome-desktop3 (or removing them).
- gobject-introspection 0.9.5+ This implies simple rebuilds of a lot of packages for the lookaside GIR/.typelib data, which is straightforward. However, updating to this version also implies pulling in a new pygobject, which has had quite a bit of code changes. Upstream feels confident, but it's just one thing that weighs against an update (a possible alternative path is to disable introspection from pygobject).
So the alternative here is: - Add a warning/note to F14 gnome-shell that it's old and to: - Make it easier and better to run F15/rawhide. Which involves fixing the problems there, and scripting the rpm/yum foo better to make the switch, and being a lot more aggressive about preventing regressions.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 09/29/2010 09:02 AM, Colin Walters wrote:
I just had a discussion with Owen about the state of F14+gnome-shell, and wanted to give an update on why we decided not to try updating it from the current state (last updated Jul 13), and concentrate on F15 instead.
So most of the development has been happening in git/jhbuild, and we haven't even managed to get rawhide updated due to the XULRunner changes (work on rawhide is proceeding now, https://bugzilla.gnome.org/show_bug.cgi?id=622896 for the curious).
Now, multiple things would need to occur for F14:
Separate clutter 1.4 parallel install package Impact on critical path: None. Sort of ugly is the only thing.
Updated GTK3 package Impact on critical path: Low/None (some things in F14 oddly
require gtk3 that shouldn't, like seed...needs investigation). But we'd *also* have to look at either updating packages like gnome-desktop3 (or removing them).
- gobject-introspection 0.9.5+ This implies simple rebuilds of a lot of packages for the
lookaside GIR/.typelib data, which is straightforward. However, updating to this version also implies pulling in a new pygobject, which has had quite a bit of code changes. Upstream feels confident, but it's just one thing that weighs against an update (a possible alternative path is to disable introspection from pygobject).
So the alternative here is:
- Add a warning/note to F14 gnome-shell that it's old and to:
- Make it easier and better to run F15/rawhide. Which involves
fixing the problems there, and scripting the rpm/yum foo better to make the switch, and being a lot more aggressive about preventing regressions.
What about hosting a repos.fp.o for gnome-shell in F14?
- -- Jesse Keating Fedora -- Freedom² is a feature! identi.ca: http://identi.ca/jkeating
On Wed, 2010-09-29 at 09:36 -0700, Jesse Keating wrote:
On 09/29/2010 09:02 AM, Colin Walters wrote:
So the alternative here is:
- Add a warning/note to F14 gnome-shell that it's old and to:
- Make it easier and better to run F15/rawhide. Which involves
fixing the problems there, and scripting the rpm/yum foo better to make the switch, and being a lot more aggressive about preventing regressions.
What about hosting a repos.fp.o for gnome-shell in F14?
The problem here is that that repository would have to have all the updates that Colin is saying that we don't want to do now:
- Rebuilds of all the gnome libraries - New pygobject - Parallel-installed clutter-14 - Etc.
So it's a repo that would modify systems fairly drastically and would take a lot of work to maintain. Not infeasible but we do need to concentrate a lot on F15 in this cycle.
- Owen
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 09/29/2010 11:45 AM, Owen Taylor wrote:
On Wed, 2010-09-29 at 09:36 -0700, Jesse Keating wrote:
On 09/29/2010 09:02 AM, Colin Walters wrote:
So the alternative here is:
- Add a warning/note to F14 gnome-shell that it's old and to:
- Make it easier and better to run F15/rawhide. Which involves
fixing the problems there, and scripting the rpm/yum foo better to make the switch, and being a lot more aggressive about preventing regressions.
What about hosting a repos.fp.o for gnome-shell in F14?
The problem here is that that repository would have to have all the updates that Colin is saying that we don't want to do now:
- Rebuilds of all the gnome libraries
- New pygobject
- Parallel-installed clutter-14
- Etc.
So it's a repo that would modify systems fairly drastically and would take a lot of work to maintain. Not infeasible but we do need to concentrate a lot on F15 in this cycle.
- Owen
I envisioned just copies of the f15 change sets being built against f14 and published into an f14 repo. This could be done by somebody not necessarily being distracted with upstream and f15 tasks.
- -- Jesse Keating Fedora -- Freedom² is a feature! identi.ca: http://identi.ca/jkeating
I envisioned just copies of the f15 change sets being built against f14 and published into an f14 repo. This could be done by somebody not necessarily being distracted with upstream and f15 tasks.
I have an up to date legacy-build branch of mutter and gnome-shell that I will make public once I fix the performance problems with the new statusIconDispatcher. My branches carry pretty much all the patches minus the GSettings and updater Introspection stuff. I have tested it and it builds and runs on F13.
If people want to test Gnome-Shell on F14 this will be available for them.
-Jon
On Thu, Sep 30, 2010 at 1:57 AM, Jon Nettleton jon.nettleton@gmail.com wrote:
I envisioned just copies of the f15 change sets being built against f14 and published into an f14 repo. This could be done by somebody not necessarily being distracted with upstream and f15 tasks.
I have an up to date legacy-build branch of mutter and gnome-shell that I will make public once I fix the performance problems with the new statusIconDispatcher.
Just in case you have not noticed it, there is a bug open about it https://bugzilla.gnome.org/show_bug.cgi?id=630533
(Have not really tired to debug it yet; just reverted the change locally)
On Wed, Sep 29, 2010 at 8:12 PM, Jesse Keating jkeating@redhat.com wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 09/29/2010 11:45 AM, Owen Taylor wrote:
On Wed, 2010-09-29 at 09:36 -0700, Jesse Keating wrote:
On 09/29/2010 09:02 AM, Colin Walters wrote:
So the alternative here is: - Add a warning/note to F14 gnome-shell that it's old and to: - Make it easier and better to run F15/rawhide. Which involves fixing the problems there, and scripting the rpm/yum foo better to make the switch, and being a lot more aggressive about preventing regressions.
What about hosting a repos.fp.o for gnome-shell in F14?
The problem here is that that repository would have to have all the updates that Colin is saying that we don't want to do now:
- Rebuilds of all the gnome libraries - New pygobject - Parallel-installed clutter-14 - Etc.
So it's a repo that would modify systems fairly drastically and would take a lot of work to maintain. Not infeasible but we do need to concentrate a lot on F15 in this cycle.
- Owen
I envisioned just copies of the f15 change sets being built against f14 and published into an f14 repo. This could be done by somebody not necessarily being distracted with upstream and f15 tasks.
Problem with that is that it changes a lot of core libraries and would likely break the standard desktops for those users that use the 3rd party repos.
Peter
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 9/30/10 1:08 AM, Peter Robinson wrote:
I envisioned just copies of the f15 change sets being built against f14
and published into an f14 repo. This could be done by somebody not necessarily being distracted with upstream and f15 tasks.
Problem with that is that it changes a lot of core libraries and would likely break the standard desktops for those users that use the 3rd party repos.
That's kind of the point of having it be a specific gnome3 repo. If the only way to get updated gnome3 on F14 is to "break" core libraries, than that's the only way. But when it is in its own repository then people are /choosing/ to go down that path, instead of winding up on that path due to something else they wanted from that repository.
- -- Jesse Keating Fedora -- Freedom² is a feature! identi.ca: http://identi.ca/jkeating
desktop@lists.fedoraproject.org
-
Colin Walters -
drago01 -
Jesse Keating -
Jon Nettleton -
Owen Taylor -
Peter Robinson