Broken from the "Summary of Reddit thread".
Fedora's lack of a graphical major-version updater comes up constantly. I think it's probably time to start brainstorming how to solve it, with a stated intention of having things work for upgrading Fedora 23 -> Fedora 24 *at minimum* and an ideal situation of having Fedora 22 -> Fedora 23 upgrades work (with changes made during Fedora 22's stable lifecycle to support this).
So to brainstorm, I'll start with a list (in no particular order) of things I think we want as goals (not necessary technical goals but user experience goals) and then go into a few known technical enhancements that need to be accomplished to get there. (Note: many of the experience goals may already be possible with some combination of GNOME Software and/or fedup, but they are included for completeness).
Much discussion welcome!
p.s. I am not a member of the Workstation WG, but I am a highly- interested party.
== User Experience Goals == * The user must be informed that a major-version upgrade is available soon[1] after it is released in a manner that is consistent with the integrated operation of the system.
* The user must have the option to "snooze" this notification for a sensible amount of time (or permanently) to avoid nag.
* The mechanism must be capable of informing the user of how much disk space will be required to perform the update prior to their initiating one.
* The upgrade mechanism must *not* download any files other than metadata prior to a user request for upgrading.
* The upgrade mechanism, once requested, must download all packages to be upgraded locally before starting (to avoid network issues in the middle of the upgrade process).
* The distribution upgrade mechanism *must* take place in a dedicated upgrade environment with no other services running.
* The updater must be capable of first updating *itself* to the latest stable version prior to attempting an upgrade. This *may* also require updating all packages on the local system to their latest versions, if needed.
* The resultant state of the machine after an upgrade should be equivalent[1] to a freshly-installed system of the new version, configured the same way as the previous version.
* Once the system has entered the dedicated environment, the updater should[2] complete successfully or else make no changes to the installed system, when only Fedora repositories are enabled.
* The update notification should be configurable to support upgrades to Alpha and Beta releases, if desired.
== Non-goals == * It is not a requirement to be able to downgrade from a successful distribution upgrade.
== Technical implementation thoughts == * For Fedora Workstation, the obvious graphical front-end should be GNOME Software
* ... However, the low-level should be implemented by PackageKit so that other DEs can implement their own solutions.
* The fedup tool already provides a non-graphical implementation of the dedicated upgrade environment (as well as some odds-and-ends for managing changes that aren't handled by simple package upgrade scripts). This logic should be moved to PackageKit and maintained there, with fedup becoming a CLI client implementation of it.
* The Fedora infrastructure would need to add new metadata to describe releases (also supporting Alpha and Beta releases) that the upgrade mechanisms may query for. Mirror-manager is probably a good place for this.
* From a user perspective, GNOME software should provide AppStream metadata for a Fedora N+1 package, which would have special properties of enabling the distribution-upgrade. (Modeled somewhat after OSX upgrades which are done by "purchasing" the new version in their OSX app store)
* When the user receives a notification for a distribution upgrade, clicking on that notification should bring them to the upgrade entry in GNOME Software (or other tool as appropriate to other spins).
[1] Definition malleable. [2] I hate the word "should", but I don't want *every* edge case as a bug here.
----- Original Message -----
Broken from the "Summary of Reddit thread".
Fedora's lack of a graphical major-version updater comes up constantly. I think it's probably time to start brainstorming how to solve it, with a stated intention of having things work for upgrading Fedora 23 -> Fedora 24 *at minimum* and an ideal situation of having Fedora 22 -> Fedora 23 upgrades work (with changes made during Fedora 22's stable lifecycle to support this).
So to brainstorm, I'll start with a list (in no particular order) of things I think we want as goals (not necessary technical goals but user experience goals) and then go into a few known technical enhancements that need to be accomplished to get there. (Note: many of the experience goals may already be possible with some combination of GNOME Software and/or fedup, but they are included for completeness).
Much discussion welcome!
One things to add to user experience is integration with Preupgrade Assistant. One can argue it's not for Workstation use case but for Server but one of the ideas was to support desktop upgrades aka when for example an IM client is no longer default, say hey, we have very new shining IM client and you can even migrate your history via...
https://fedoraproject.org//wiki/Changes/Preupgrade_Assistant
Jaroslav
On Tue, 2015-04-07 at 06:45 -0400, Jaroslav Reznik wrote:
----- Original Message -----
Broken from the "Summary of Reddit thread".
Fedora's lack of a graphical major-version updater comes up constantly. I think it's probably time to start brainstorming how to solve it, with a stated intention of having things work for upgrading Fedora 23 -> Fedora 24 *at minimum* and an ideal situation of having Fedora 22 -> Fedora 23 upgrades work (with changes made during Fedora 22's stable lifecycle to support this).
So to brainstorm, I'll start with a list (in no particular order) of things I think we want as goals (not necessary technical goals but user experience goals) and then go into a few known technical enhancements that need to be accomplished to get there. (Note: many of the experience goals may already be possible with some combination of GNOME Software and/or fedup, but they are included for completeness).
Much discussion welcome!
One things to add to user experience is integration with Preupgrade Assistant. One can argue it's not for Workstation use case but for Server but one of the ideas was to support desktop upgrades aka when for example an IM client is no longer default, say hey, we have very new shining IM client and you can even migrate your history via...
https://fedoraproject.org//wiki/Changes/Preupgrade_Assistant
Jaroslav
Well, the user experience goals should express a need from the users, not an implication of a specific technology. So perhaps something like:
* When an upgrade will require or recommend a migration from one piece of software to another, the user should be presented with a choice or a notice (whichever is appropriate to the situation).
On Tue, 2015-04-07 at 06:45 -0400, Jaroslav Reznik wrote:
----- Original Message -----
Broken from the "Summary of Reddit thread".
Fedora's lack of a graphical major-version updater comes up constantly. I think it's probably time to start brainstorming how to solve it, with a stated intention of having things work for upgrading Fedora 23 -> Fedora 24 *at minimum* and an ideal situation of having Fedora 22 -> Fedora 23 upgrades work (with changes made during Fedora 22's stable lifecycle to support this).
So to brainstorm, I'll start with a list (in no particular order) of things I think we want as goals (not necessary technical goals but user experience goals) and then go into a few known technical enhancements that need to be accomplished to get there. (Note: many of the experience goals may already be possible with some combination of GNOME Software and/or fedup, but they are included for completeness).
Much discussion welcome!
One things to add to user experience is integration with Preupgrade Assistant. One can argue it's not for Workstation use case but for Server but one of the ideas was to support desktop upgrades aka when for example an IM client is no longer default, say hey, we have very new shining IM client and you can even migrate your history via...
https://fedoraproject.org//wiki/Changes/Preupgrade_Assistant
I don't think this is part of my ideal graphical upgrade experience, tbh. It is basically a collection of workarounds for all the places where upgrade doesn't work.
If we want to discuss better approaches to upgrading a system, here is an alternative design: https://wiki.gnome.org/Design/OS/Migration The premise there is that it is much better to do a selective export/import of your important data, and do a fresh install, instead of trying to manage all the ways in which a huge, system-wide upgrade can fail. Of course, this is quite different from what fedup is doing today, and we don't have any code for this.
On Mon, 06 Apr 2015 16:56:31 -0400 Stephen Gallagher sgallagh@redhat.com wrote:
Broken from the "Summary of Reddit thread".
Fedora's lack of a graphical major-version updater comes up constantly. I think it's probably time to start brainstorming how to solve it, with a stated intention of having things work for upgrading Fedora 23 -> Fedora 24 *at minimum* and an ideal situation of having Fedora 22 -> Fedora 23 upgrades work (with changes made during Fedora 22's stable lifecycle to support this).
I think this brainstorming should include right now the fedup maintainer(s). It seems odd to me to start discussing this on this list without first asking them plans and roping them into the discussion.
...snip lots of stuff that fedup already does and some it doesn't yet....
- For Fedora Workstation, the obvious graphical front-end should be
GNOME Software
- ... However, the low-level should be implemented by PackageKit so
that other DEs can implement their own solutions.
Why reimplement fedup in PackageKit? Or is that not what you are saying?
- The fedup tool already provides a non-graphical implementation of
the dedicated upgrade environment (as well as some odds-and-ends for managing changes that aren't handled by simple package upgrade scripts). This logic should be moved to PackageKit and maintained there, with fedup becoming a CLI client implementation of it.
Well, I am not a fedup maintainer, but that seems... odd to dictacte.
Why is PackageKit a better place for it?
IMHO, I think it would make sense to keep fedup as the cli/backend and have gnome-software or perhaps a dedicated fedup gui frontend interface with it.
- The Fedora infrastructure would need to add new metadata to
describe releases (also supporting Alpha and Beta releases) that the upgrade mechanisms may query for. Mirror-manager is probably a good place for this.
fedup already has this.
kevin
On Tue, 2015-04-07 at 09:03 -0600, Kevin Fenzi wrote:
Why reimplement fedup in PackageKit? Or is that not what you are saying?
Well, it should be implemented in GNOME Software: that much we're sure of. Here are our designs:
https://raw.githubusercontent.com/gnome-design-team/gnome-mockups/34b4e00933...
I don't mind using fedup to perform the upgrade, but I'd prefer it to be done in some distro-agnostic way (so PackageKit is strongly- indicated, at least), so that other distros can use GNOME Software for upgrades, too.
PackageKit actually used to support distro upgrades. Richard deleted the code a year or two ago because nobody was using it.
Michael
On Tue, 2015-04-07 at 11:40 -0500, Michael Catanzaro wrote:
On Tue, 2015-04-07 at 09:03 -0600, Kevin Fenzi wrote:
Why reimplement fedup in PackageKit? Or is that not what you are saying?
Well, it should be implemented in GNOME Software: that much we're sure of. Here are our designs:
Hyperlink attempt #2:
https://raw.githubusercontent.com/gnome-design-team/gnome-mockups/master/sof...
On 07/04/15 09:40 AM, Michael Catanzaro wrote:
Well, it should be implemented in GNOME Software: that much we're sure of. Here are our designs:
https://raw.githubusercontent.com/gnome-design-team/gnome-mockups/34b4e00933...
I don't mind using fedup to perform the upgrade, but I'd prefer it to be done in some distro-agnostic way (so PackageKit is strongly- indicated, at least), so that other distros can use GNOME Software for upgrades, too.
PackageKit actually used to support distro upgrades. Richard deleted the code a year or two ago because nobody was using it.
It will be the time to revive the code because some other distributions notably Arch are increasingly adopting Gnome Software. If that mechanism was left unused, what were its shortcoming?
On 8 April 2015 at 18:24, Luya Tshimbalanga luya@fedoraproject.org wrote:
It will be the time to revive the code because some other distributions notably Arch are increasingly adopting Gnome Software. If that mechanism was left unused, what were its shortcoming?
Nobody wanted to maintain the distro upgrade implementation. If someone other than me is volunteering to do the work, I'll gladly revert the removal.
Richard.
On Tue, Apr 7, 2015 at 5:03 PM, Kevin Fenzi kevin@scrye.com wrote:
On Mon, 06 Apr 2015 16:56:31 -0400 Stephen Gallagher sgallagh@redhat.com wrote:
Broken from the "Summary of Reddit thread".
Fedora's lack of a graphical major-version updater comes up constantly. I think it's probably time to start brainstorming how to solve it, with a stated intention of having things work for upgrading Fedora 23 -> Fedora 24 *at minimum* and an ideal situation of having Fedora 22 -> Fedora 23 upgrades work (with changes made during Fedora 22's stable lifecycle to support this).
I think this brainstorming should include right now the fedup maintainer(s). It seems odd to me to start discussing this on this list without first asking them plans and roping them into the discussion.
...snip lots of stuff that fedup already does and some it doesn't yet....
- For Fedora Workstation, the obvious graphical front-end should be
GNOME Software
- ... However, the low-level should be implemented by PackageKit so
that other DEs can implement their own solutions.
Why reimplement fedup in PackageKit? Or is that not what you are saying?
- The fedup tool already provides a non-graphical implementation of
the dedicated upgrade environment (as well as some odds-and-ends for managing changes that aren't handled by simple package upgrade scripts). This logic should be moved to PackageKit and maintained there, with fedup becoming a CLI client implementation of it.
Well, I am not a fedup maintainer, but that seems... odd to dictacte.
Why is PackageKit a better place for it?
IMHO, I think it would make sense to keep fedup as the cli/backend and have gnome-software or perhaps a dedicated fedup gui frontend interface with it.
- The Fedora infrastructure would need to add new metadata to
describe releases (also supporting Alpha and Beta releases) that the upgrade mechanisms may query for. Mirror-manager is probably a good place for this.
fedup already has this.
Well gnome-software's offline update is not much different from fedup modulo the initrd / dracut stuff. If we add that they would be more or less the same.
On 04/06/2015 10:56 PM, Stephen Gallagher wrote:
Broken from the "Summary of Reddit thread".
Fedora's lack of a graphical major-version updater comes up constantly. I think it's probably time to start brainstorming how to solve it, with a stated intention of having things work for upgrading Fedora 23 -> Fedora 24 *at minimum* and an ideal situation of having Fedora 22 -> Fedora 23 upgrades work (with changes made during Fedora 22's stable lifecycle to support this).
Is this really a good use of development resources? I mean, really—if developers are the primary user group, is it unreasonable to expect that they will use a shell once or twice per year to perform the upgrades?
On 8 April 2015 at 08:52, Florian Weimer fweimer@redhat.com wrote:
if developers are the primary user group, is it unreasonable to expect that they will use a shell once or twice per year to perform the upgrades?
That's a big "if", isn't it? Do we have any real figures about who our users are, or plans to find out? I digress, but it seems like a short survey of the kind Stack Overflow did (and Matthew Miller mentioned in another thread) might be a good way to learn more about our users, especially if it's triggered during initial set-up or post-upgrade.
It may be fair to say that developers are our primary target user group, in which case I agree that expecting them to use a shell to upgrade is fine (It's not like "sudo fedup --network 22" is a complicated command). Still, notifying the user that there's a new major version available to upgrade to is worthwhile. There's an argument that targeting developers is a bit of a cop-out though; assuming some technical expertise on behalf of our users could be an excuse not to make stuff as user-friendly as it might be.
I've actually installed Fedora for a couple of my family members because I think GNOME Shell provides a more user-friendly UI than many alternatives, and Fedora ships a great GNOME Shell set-up. As Fedora users they're in a very small minority I'm sure, but they'd certainly benefit from a graphical upgrade process (or at least, I would in that I'd not need to do the upgrades for them).
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512
hi I'll second this. I'm relatively new to the fedora community, so I don't know whether fedora's primary audience is developers or not. That being said, I'm not one, and I like user friendly, although I can run terminal commands when needed or if I want to. That being said, since gnome is moving towards user friendly everything, software management, eventually uefi firmware upgrades, it makes sense to handle distro upgrades as well, and if possible in a distro agnostic way if at all possible. Of course, since fedora is a very large contributor to gnome it seems only fair that it be the first to be able to be upgraded graphically. I would though, provide a big warning text before attempting to upgrade the distro graphically. If the user has 3rd party repositories that are unknown to fedora, such as the ever popular rpmfusion, any graphical upgrade method is likely not to be able to upgrade those cleanly, if at all, so either the user will have to disable them manually or the upgrader could do it, and either re-enable them upon reboot or tell the user to do it. Thanks Kendell clark Sent from Fedora GNU/Linux
Richard Turner wrote:
On 8 April 2015 at 08:52, Florian Weimer fweimer@redhat.com wrote:
if developers are the primary user group, is it unreasonable to expect that they will use a shell once or twice per year to perform the upgrades?
That's a big "if", isn't it? Do we have any real figures about who our users are, or plans to find out? I digress, but it seems like a short survey of the kind Stack Overflow did (and Matthew Miller mentioned in another thread) might be a good way to learn more about our users, especially if it's triggered during initial set-up or post-upgrade.
It may be fair to say that developers are our primary target user group, in which case I agree that expecting them to use a shell to upgrade is fine (It's not like "sudo fedup --network 22" is a complicated command). Still, notifying the user that there's a new major version available to upgrade to is worthwhile. There's an argument that targeting developers is a bit of a cop-out though; assuming some technical expertise on behalf of our users could be an excuse not to make stuff as user-friendly as it might be.
I've actually installed Fedora for a couple of my family members because I think GNOME Shell provides a more user-friendly UI than many alternatives, and Fedora ships a great GNOME Shell set-up. As Fedora users they're in a very small minority I'm sure, but they'd certainly benefit from a graphical upgrade process (or at least, I would in that I'd not need to do the upgrades for them).
On Wed, Apr 08, 2015 at 09:41:26AM +0100, Richard Turner wrote:
if developers are the primary user group, is it unreasonable to expect that they will use a shell once or twice per year to perform the upgrades?
That's a big "if", isn't it?
It is the target audience for Fedora Workstation, which is a subset of Fedora overall — but also one of our current big, main areas of focus. See: https://fedoraproject.org/wiki/Workstation/Workstation_PRD and, for that matter, https://getfedora.org/.
Do we have any real figures about who ourusers are, or plans to find out? I digress, but it seems like a short survey of the kind Stack Overflow did (and Matthew Miller mentioned in another thread) might be a good way to learn more about our users, especially if it's triggered during initial set-up or post-upgrade.
We've had on-and-off plans but it hasn't gone very far yet. However, this is one of the things Remy DeCausemaker, who fills the new "Community Action and Impact" role on the Fedora Council, will be working on. Metrics are important, for decision making and for validating that those decisions were right.
It may be fair to say that developers are our primary target user group, in which case I agree that expecting them to use a shell to upgrade is fine (It's not like "sudo fedup --network 22" is a complicated command). Still, notifying the user that there's a new major version available to upgrade to is worthwhile. There's an argument that targeting developers is a bit of a cop-out though; assuming some technical expertise on behalf of our users could be an excuse not to make stuff as user-friendly as it might be.
I think this concern is fairly well addressed in the PRD above....
On 8 Apr 2015 10:00 pm, "Matthew Miller" mattdm@fedoraproject.org wrote:
On Wed, Apr 08, 2015 at 09:41:26AM +0100, Richard Turner wrote:
if developers are the primary user group, is it unreasonable to expect that they will use a shell once or twice per year to perform the
upgrades?
That's a big "if", isn't it?
It is the target audience for Fedora Workstation, which is a subset of Fedora overall — but also one of our current big, main areas of focus.
I merely meant that's an "if" because although developers are (since the inception of Workstation) our primarily targeted audience, that doesn't magically make all our users developers. Most users will be those that have used Fedora for years. Can we say with any confidence what their technical competencies are?
It's good there are plans afoot to survey our users, we may be surprised at how many aren't developers.
On Thu, Apr 09, 2015 at 07:55:38AM +0100, Richard Turner wrote:
That's a big "if", isn't it?
It is the target audience for Fedora Workstation, which is a subset of Fedora overall — but also one of our current big, main areas of focus.
I merely meant that's an "if" because although developers are (since the inception of Workstation) our primarily targeted audience, that doesn't magically make all our users developers. Most users will be those that have used Fedora for years. Can we say with any confidence what their technical competencies are?
That's true, and while we absolutely don't want to abandon those users, the Workstation plan is aimed at attracting _new_ users from a segment in which we should be able to have a lot of growth.
It's good there are plans afoot to survey our users, we may be surprised at how many aren't developers.
Oh, I won't be surprised. I'm certain it's a lot. :)
On Wed, 2015-04-08 at 09:52 +0200, Florian Weimer wrote:
Is this really a good use of development resources? I mean, really—if developers are the primary user group, is it unreasonable to expect that they will use a shell once or twice per year to perform the upgrades?
Even if we only cared about developers, I would say that I do not expect developers to use the terminal or to know that fedup exists. But this is the beginning of the PRD we agreed on:
"We want to create a stable, integrated, polished and user friendly system that can appeal to a wide general audience. The Fedora Workstation working group will have a special focus on providing a platform for development of various types of applications."
Developers are a "special focus" and that warrants making some decisions that we wouldn't otherwise, e.g. I'm interested in installing more command-line development tools like gcc by default. But it would be a mistake to take this so far that we compromise user- friendliness or our appeal to a "wide, general audience." That's one of the reasons that developers are using Macs instead of Fedora, after all.
Michael
On Wed, Apr 8, 2015 at 7:42 AM, Michael Catanzaro mcatanzaro@gnome.org wrote:
On Wed, 2015-04-08 at 09:52 +0200, Florian Weimer wrote:
Is this really a good use of development resources? I mean, really—if developers are the primary user group, is it unreasonable to expect that they will use a shell once or twice per year to perform the upgrades?
Even if we only cared about developers, I would say that I do not expect developers to use the terminal or to know that fedup exists. But this is the beginning of the PRD we agreed on:
"We want to create a stable, integrated, polished and user friendly system that can appeal to a wide general audience. The Fedora Workstation working group will have a special focus on providing a platform for development of various types of applications."
Developers are a "special focus" and that warrants making some decisions that we wouldn't otherwise, e.g. I'm interested in installing more command-line development tools like gcc by default. But it would be a mistake to take this so far that we compromise user- friendliness or our appeal to a "wide, general audience." That's one of the reasons that developers are using Macs instead of Fedora, after all.
The #1 thing Apple does to achieve polish is say no. This is so pervasive it's thematic. But constraining the context to install, updates, and upgrades, both Apple and users gain a lot through simply having less.
~ 90% of Custom partitioning is incompatible with stable, integrated, polished, and user friendly. It's a massive amount of feature sprawl, permitting arbitrary layouts that bind the bootloader, the user, backup/restore software, offline updates, and fedup upgrades, into understanding and supporting. There are nearly endless bugs in this area.
Much of what custom permits, binds us to one of two choices: supporting arbitrary layouts, or broken functionality as a result of them. And I've lost count how many of these bugs I've filed, let alone how many I keep running into and just don't have the will power to keep filing because so many keep getting marked as not bugs, or not a priority to ever fix.
Windows and Android do stateless better. Apple does updates, backup and restore better. Their approaches are completely different in this area, except with one respect: they both have a lot of discipline to just say no. So there's room for Fedora to be different and better than OS X or Windows in this area, but not until we create a spec or standard and stop giving users razor blades and telling them to go play on the freeway.
And that spec/standard's mandate would be looking at a dozen packages, how they all affect each other in terms of UI/UX and how to constrain what's permitted up front, in order to gain stable, user friendly, polish at the back end as a result of sane focus.
On Wed, Apr 8, 2015 at 9:56 AM, Chris Murphy lists@colorremedies.com wrote:
And that spec/standard's mandate would be looking at a dozen packages, how they all affect each other
Each of these things directly affects one or more of the others, and in my opinion cannot be meaningfully discussed in isolation:
- bootloaders (including bootloader spec) - partitioning/filesystems - OS install, updates, upgrades - resets/statelessness (or lack thereof) - snapshots/rollbacks - backup and restore (emphasis on restore which implies something must repartition) - application installation - ostree/Project Atomic
Is sorting out some of the plumbing related interactions, pros & cons, more the domain of Base WG or Env & Stacks WG?
On Wed, Apr 8, 2015 at 9:52 AM, Florian Weimer fweimer@redhat.com wrote:
On 04/06/2015 10:56 PM, Stephen Gallagher wrote:
Broken from the "Summary of Reddit thread".
Fedora's lack of a graphical major-version updater comes up constantly. I think it's probably time to start brainstorming how to solve it, with a stated intention of having things work for upgrading Fedora 23 -> Fedora 24 *at minimum* and an ideal situation of having Fedora 22 -> Fedora 23 upgrades work (with changes made during Fedora 22's stable lifecycle to support this).
Is this really a good use of development resources? I mean, really—if developers are the primary user group, is it unreasonable to expect that they will use a shell once or twice per year to perform the upgrades?
That might surprise you but no; there are developers who aren't really used to a terminal and are uncomfortable using it "that's like DOS". Those coming from the Windows side ... the (developer) world does not consists of UNIX (Linux + OS X) users but the vast majority is using Windows.
----- Original Message -----
From: "drago01" drago01@gmail.com To: "Discussions about development for the Fedora desktop" desktop@lists.fedoraproject.org Sent: Thursday, April 9, 2015 8:33:00 AM Subject: Re: Graphical Distribution Upgrades
On Wed, Apr 8, 2015 at 9:52 AM, Florian Weimer fweimer@redhat.com wrote:
On 04/06/2015 10:56 PM, Stephen Gallagher wrote:
Broken from the "Summary of Reddit thread".
Fedora's lack of a graphical major-version updater comes up constantly. I think it's probably time to start brainstorming how to solve it, with a stated intention of having things work for upgrading Fedora 23 -> Fedora 24 *at minimum* and an ideal situation of having Fedora 22 -> Fedora 23 upgrades work (with changes made during Fedora 22's stable lifecycle to support this).
Is this really a good use of development resources? I mean, really—if developers are the primary user group, is it unreasonable to expect that they will use a shell once or twice per year to perform the upgrades?
That might surprise you but no; there are developers who aren't really used to a terminal and are uncomfortable using it "that's like DOS". Those coming from the Windows side ... the (developer) world does not consists of UNIX (Linux + OS X) users but the vast majority is using Windows. --
I would also want to point out that being able to use the command line isn't the same as wanting to at every opportunity. The challenge with command line stuff is that they tend to require more work from the users in terms of reading docs or howtos. So while using command lines might be quicker and more efficient for stuff you want to do on a daily basis, for the reason I explained above they can be really annoying for this you do on an irregular basis. For instance I personally use git so rarely these days that I have to google for the commands everytime I want to tag a release to get the syntax right. So I think that even people who like using the command line prefer having easy to use graphic tools for tasks they don't do all the time, because the graphics tools can be a lot of self explanatory if designed well.
Another example is that there is quite a bit of excitement in the Docker community these days about Kitematic, so while one could claim that the docker developers are 'command line' people, they still like having nice UI tools for certain things.
And I think the annoyance with command line tools tend to be a bit cumulative, so nobody would probably be to annoyed if they had one thing they did once a year requiring a set of terminal commands, but as things requiring command line interactions add up and you feel you need to google for commands on a weekly basis it for sure becomes an annoyance, especially if you know that other operating systems do not require this of you.
So we don't have the resources of course to provide UI tools for every possible task out there, but I think system upgrades is such a core thing of your system that we want to make it feel polished and effortless.
Christian
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512
hi I'll second this. System upgrades sound simple on the surface, but they're among the hardest to troubleshoot if something goes wrong, so if we do this, we need to make sure it's as bulletproof as possible, and that means dealing with nontraditional ... well, pretty much everything. Strange partition layouts, 3rd party repos, the works. If we don't, we're likely to get some windows user in our irc channels ... well, being windows users. Why isn't this working, windows "just works" ... etc. Back on topic. I'd be willing to test this if a graphical distro upgrader ever becomes available, especially for accessibility. Could I make a request while I'm at it? If one is implemented, would it be possible to have an upgrade screen similar to the fedora welcome screen, but containing upgrade progress messages and a progress bar? I know plymouth method is easier but there's no way for accessibility tools to get at that info so I'm stuck looking at a redhat logo and some text I can't read while it upgrades. Of course, this brings the question of can gdm be upgraded while it's being used to display that screen? I'm not sure, I'm still new to fedora, having switched a month ago. Thanks Kendell clark Sent from Fedora GNU/Linux
Christian Schaller wrote:
----- Original Message -----
From: "drago01" drago01@gmail.com To: "Discussions about development for the Fedora desktop" desktop@lists.fedoraproject.org Sent: Thursday, April 9, 2015 8:33:00 AM Subject: Re: Graphical Distribution Upgrades
On Wed, Apr 8, 2015 at 9:52 AM, Florian Weimer fweimer@redhat.com wrote:
On 04/06/2015 10:56 PM, Stephen Gallagher wrote:
Broken from the "Summary of Reddit thread".
Fedora's lack of a graphical major-version updater comes up constantly. I think it's probably time to start brainstorming how to solve it, with a stated intention of having things work for upgrading Fedora 23 -> Fedora 24 *at minimum* and an ideal situation of having Fedora 22 -> Fedora 23 upgrades work (with changes made during Fedora 22's stable lifecycle to support this).
Is this really a good use of development resources? I mean, really—if developers are the primary user group, is it unreasonable to expect that they will use a shell once or twice per year to perform the upgrades?
That might surprise you but no; there are developers who aren't really used to a terminal and are uncomfortable using it "that's like DOS". Those coming from the Windows side ... the (developer) world does not consists of UNIX (Linux + OS X) users but the vast majority is using Windows. --
I would also want to point out that being able to use the command line isn't the same as wanting to at every opportunity. The challenge with command line stuff is that they tend to require more work from the users in terms of reading docs or howtos. So while using command lines might be quicker and more efficient for stuff you want to do on a daily basis, for the reason I explained above they can be really annoying for this you do on an irregular basis. For instance I personally use git so rarely these days that I have to google for the commands everytime I want to tag a release to get the syntax right. So I think that even people who like using the command line prefer having easy to use graphic tools for tasks they don't do all the time, because the graphics tools can be a lot of self explanatory if designed well.
Another example is that there is quite a bit of excitement in the Docker community these days about Kitematic, so while one could claim that the docker developers are 'command line' people, they still like having nice UI tools for certain things.
And I think the annoyance with command line tools tend to be a bit cumulative, so nobody would probably be to annoyed if they had one thing they did once a year requiring a set of terminal commands, but as things requiring command line interactions add up and you feel you need to google for commands on a weekly basis it for sure becomes an annoyance, especially if you know that other operating systems do not require this of you.
So we don't have the resources of course to provide UI tools for every possible task out there, but I think system upgrades is such a core thing of your system that we want to make it feel polished and effortless.
Christian
Another challenge, tangential from upgrades: hybrid graphics. Apple's been doing this for 5+ years, with completely seamless switching between integrated and discrete graphics. More recently it's increasing in popularity among even mid-range non-Apple hardware.
And the kernel honestly doesn't do well here, it often gets the switching confused, and as far as I know there's no on-the-fly switching based on usage. The plus for the user is integrated graphics for better battery life, and discrete graphics for heavy lifting software and when running on a power adapter - best of both.
Maybe the seamless switching becomes possible with Wayland? But the intermittent confusion before x even starts is presumably kernel confusion (and regressions). I'm not sure what the solution is, but it's understandable users will pick the path of least resistance. That doesn't mean Fedora itself is doing something wrong that it can obviously correct.
-- Chris Murphy
On Fri, Apr 10, 2015 at 2:54 AM, Chris Murphy lists@colorremedies.com wrote:
Another challenge, tangential from upgrades: hybrid graphics. Apple's been doing this for 5+ years, with completely seamless switching between integrated and discrete graphics. More recently it's increasing in popularity among even mid-range non-Apple hardware.
And the kernel honestly doesn't do well here, it often gets the switching confused, and as far as I know there's no on-the-fly switching based on usage. The plus for the user is integrated graphics for better battery life, and discrete graphics for heavy lifting software and when running on a power adapter - best of both.
Maybe the seamless switching becomes possible with Wayland? But the intermittent confusion before x even starts is presumably kernel confusion (and regressions). I'm not sure what the solution is, but it's understandable users will pick the path of least resistance. That doesn't mean Fedora itself is doing something wrong that it can obviously correct.
https://bugzilla.gnome.org/show_bug.cgi?id=734346 https://bugzilla.gnome.org/show_bug.cgi?id=704387
I have no clue what you mean with "kernel confusion". But non of these has anything to do with upgrades.
On Fri, Apr 10, 2015 at 4:13 AM, drago01 drago01@gmail.com wrote:
On Fri, Apr 10, 2015 at 2:54 AM, Chris Murphy lists@colorremedies.com wrote:
Another challenge, tangential from upgrades: hybrid graphics. Apple's been doing this for 5+ years, with completely seamless switching between integrated and discrete graphics. More recently it's increasing in popularity among even mid-range non-Apple hardware.
And the kernel honestly doesn't do well here, it often gets the switching confused, and as far as I know there's no on-the-fly switching based on usage. The plus for the user is integrated graphics for better battery life, and discrete graphics for heavy lifting software and when running on a power adapter - best of both.
Maybe the seamless switching becomes possible with Wayland? But the intermittent confusion before x even starts is presumably kernel confusion (and regressions). I'm not sure what the solution is, but it's understandable users will pick the path of least resistance. That doesn't mean Fedora itself is doing something wrong that it can obviously correct.
https://bugzilla.gnome.org/show_bug.cgi?id=734346 https://bugzilla.gnome.org/show_bug.cgi?id=704387
I have no clue what you mean with "kernel confusion". But non of these has anything to do with upgrades.
Like I said, tangential to upgrades. A significant part of this thread's context is comparison to OS X, and the area of graphics performance and stability is where OS X excels a lot better in pretty much every possible describable way. Right now with 3.19 and 4.0 kernels there's a rather significant i915 regression happening that results in total panics and no recovery. Using discrete graphics makes the system hot, results in CPU high temp messages, MCE errors,[1] and tainted kernels. And 2 hour battery life instead of 6. It's been like this on every hybrid Mac I've tested with either Intel+nVidia or Intel+AMD graphics. As these problems start to get sorted out, the hardware is at a 3-4 year EOL.
By kernel confusion I mean it doesn't know which GPU to exclusively use, and the result is either garbage on the display or a black screen. In the i915+AMD case, blacklisting the Radeon driver isn't enough, it has to be disabled in GRUB to use i915 graphics. [2] I can't actually use only i915 graphics unless I do that.
I don't know how we do better in this area without clobbering the problem with more developers poking hardware with sticks, or a meaningful push for open hardware. The trend in mobile is, if anything, even more closed than the closedness we've seen with laptops.
[1] https://bugzilla.redhat.com/show_bug.cgi?id=924570 [2] https://bugzilla.redhat.com/show_bug.cgi?id=765954
On Thu, Apr 9, 2015 at 11:45 PM, kendell clark coffeekingms@gmail.com wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512
hi I'll second this. System upgrades sound simple on the surface, but they're among the hardest to troubleshoot if something goes wrong [..]
Technically there is no difference between a system upgrade and a simple update that we push every week other than the number of involved packages. The only issues arise from big migrations like usrmove or when packages gets replaced by others (i.e. obsolete / provides have to be correct). The latter can also happen for regular updates.
Might be disappointing to some but upgrades aren't that "special" as most people think.
desktop@lists.fedoraproject.org
-
Chris Murphy -
Christian Schaller -
drago01 -
Florian Weimer -
Jaroslav Reznik -
kendell clark -
Kevin Fenzi -
Luya Tshimbalanga -
Matthew Miller -
Matthias Clasen -
Michael Catanzaro -
Richard Hughes -
Richard Turner -
Stephen Gallagher