(In reply to František Zatloukal from comment #0)
> GNOME Software should require all packages to be updated to latest available
> version.

Why require the user to download 1Gb of updates just to prompt them to do a 1.2Gb upgrade? I've tested this with F23 GA + COPR and it works fine.

Requiring this might be too strong. But it should definitely strongly recommend this. We've had critical issues in the past that were fixed by updates either to the update software itself (fedup, dnf-plugin-system-upgrade), or to the system (systemd, etc). If people were not running the latest software, they were affected by it. All our upgrade guides strongly recommend applying the latest stable updates before upgrading.

(In reply to Richard Hughes from comment #1)
> Why require the user to download 1Gb of updates just to prompt them to do a
> 1.2Gb upgrade? I've tested this with F23 GA + COPR and it works fine.

It worked on your package set at this point of time. It might not be the case for a different package set or in a different point of time. During the past releases, we have fixed numerous important issues just days before releasing FN+1. It's likely it will happen again in the future.

(In reply to Richard Hughes from comment #1)
> Why require the user to download 1Gb of updates just to prompt them to do a
> 1.2Gb upgrade? I've tested this with F23 GA + COPR and it works fine.

My initial thought was that the upgrade path from fully updated system is much more tested by users and developers and is safer than the upgrade path from system with months old packages.

(In reply to Kamil Páral from comment #2)
> Requiring this might be too strong. But it should definitely strongly
> recommend this.

Where would we do this? From the "Learn more" hyperlink perhaps?

(In reply to Richard Hughes from comment #4)
> (In reply to Kamil Páral from comment #2)
> > Requiring this might be too strong. But it should definitely strongly
> > recommend this.
> 
> Where would we do this? From the "Learn more" hyperlink perhaps?

It's not sufficient IMO to mention this in Learn More. I think some sort of pop-up window when user tries to upgrade if there are updates available.

(In reply to Richard Hughes from comment #4)
> Where would we do this? From the "Learn more" hyperlink perhaps?

I was thinking about a colored notification bar below or above the upgrade banner saying something like "It is recommended to fully update your system first before upgrading to a newer Fedora release". The bar would be shown only if gnome-software detects that some updates are available, otherwise it would not show.

That needs to go to Allan then; it's also a string addition which would be hard for F24 and F23.

Just to add one more argument - imagine there's a problem in the updater itself (gnome-software, packagekit, libhif, etc). We don't need to think about any arbitrary issues, here's a ton of issues we were dealing with regarding system upgrades in F23:
https://bugzilla.redhat.com/showdependencytree.cgi?id=1308538&hide_resolved=0

Many of them are very important or even critical for the user. If you want them to be fixed before performing the system upgrade (and therefore not affect negatively our users), you need to guide the users properly (recommending to do an update first, and system upgrade later).

I agree with Richard that users should not have to do this two-step dance. If it's required to make upgrades reliable, then gnome-software can abstract it so it all appears as if it's one operation.

This message is a reminder that Fedora 23 is nearing its end of life.
Approximately 4 (four) weeks from now Fedora will stop maintaining
and issuing updates for Fedora 23. It is Fedora's policy to close all
bug reports from releases that are no longer maintained. At that time
this bug will be closed as EOL if it remains open with a Fedora  'version'
of '23'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version.

Thank you for reporting this issue and we are sorry that we were not 
able to fix it before Fedora 23 is end of life. If you would still like 
to see this bug fixed and are able to reproduce it against a later version 
of Fedora, you are encouraged  change the 'version' to a later Fedora 
version prior this bug is closed as described in the policy above.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

There is a very simple and a very real use case for this - the GPG keys of the new release are added as an update to the existing release. So if you haven't updated first, you might not even be able to upgrade at all. Of course, an error message like "GPG keys are missing" is cryptic to a common user. But a recommendation to fully update first can be well understandable.

I strongly agree with kparal here on the general principle: g-s should strongly recommend that the system is updated before being upgraded. If you'd rather implement that by just having the upgrade do the update before it upgrades that'd be fine, so long as it's implemented in such a way that the upgrade is done with the updated packages. We don't care how it *looks* so much. We just care about the effect.

(In reply to Adam Williamson from comment #12)
> If
> you'd rather implement that by just having the upgrade do the update before
> it upgrades that'd be fine

That'd be much better, there's no reason to allow the user to screw this up. If two reboots are required, well Windows might require three so whatever. :)

*** Bug 1455673 has been marked as a duplicate of this bug. ***

See bug 1336435 for more arguments. Proposing as a prioritized bug.

Sorry about that. I just wanted to subscribe and didn't get the usual "mid-air collision" prompt.

Discussed at 2017-06-05 blocker review meeting: https://meetbot-raw.fedoraproject.org/fedora-blocker-review/2017-06-05/f26-blocker-review.2017-06-05-16.01.html . Under the blocker review process this seems more like a feature request than exactly a bug and it is rejected as a blocker, as in itself it does not violate any criteria. We note that it may be an appropriate case for a FESCo override, or the 'prioritized bug' process.

As a side note, DNF now warns that existing updates should be installed first, before system-upgrade. See bug 1225442.

Of course GNOME Software should not display such a warning, it should just do the right thing and download/apply the current release updates transparently to the user as part of the upgrade process before moving on to the current release.

*before moving on to the new release

The bug has been added to the list of prioritized bugs on 2017-Aug-02.
https://meetbot.fedoraproject.org/fedora-meeting/2017-08-02/fedora_prioritized_bugs_and_issues.2017-08-02-14.01.log.html#l-30

Richard, is there any progress on this bug ? We would be happy if this can be fixed for F27 Final release.

This bug has been accepted as a PrioritizedBug. Since it is still in the "NEW" state, the triage team will revisit it at the 2018-08-29 meeting. If you have any updates, you can provide them here or email triage.org.

Unless someone can tell us a list of packages that have to be applied before doing the upgrade I don't think this bug can get fixed. The UX and UI don't really support "blocking" a distro upgrade until "the updates are done". Updates become available when the metadata is refreshed, sometimes behind the back of gnome-software. Updates are package upgrades, flatpaks, shell extensions, plugins, firmware and os-updates. In the backend they are separate requests and I don't really want the front-end shell to get involved with Fedora policy.

Additionally, having to install updates for an upgrade is a huge waste of bandwidth for something that's apparently not any better tested than before.

If someone tells us "don't allow the update until rpm v 5.1 and dnf version 6.2 have been installed -- here's a json file you can auto download for the requirements for each distro upgrade" that's something concrete we can work with. Something fluffy like "all updates are applied" just isn't precise enough to design for or implement. Sorry.

Hello Richard, sorry but I need to argue with you on this one. The DNF team already implemented this, if you run dnf system-upgrade, it asks you this:

> Before you continue ensure that your system is fully upgraded by running "dnf --refresh upgrade". Do you want to continue [y/N]: 

As you can see, this doesn't have to be mandatory, but it should be at least a strong suggestion. And I don't think showing a banner or popping up a dialog is that difficult to do (see comment 6). The crucial point here is that the user is *informed*.

> Updates become available when the metadata is refreshed, sometimes behind the back of gnome-software.

Since metadata is auto-refreshed by default, I believe it's quite OK to implement the easiest approach possible and just look whether any updates are known to be available at this very moment.

> Updates are package upgrades, flatpaks, shell extensions, plugins, firmware and os-updates. In the backend they are separate requests and I don't really want the front-end shell to get involved with Fedora policy.

Obviously the important part here are the package updates. If you don't block but just inform/suggest, I don't think this can be seen as a 'Fedora policy'. This is universal for any OS, and helps users of any OS. It's not like bugs related to upgrade are present/fixed just in Fedora.

> Additionally, having to install updates for an upgrade is a huge waste of bandwidth for something that's apparently not any better tested than before.

It's a waste of bandwidth, yes, and it can potentially save your system that could otherwise get broken during upgrade. This whole ticket is a request to prefer safety over speed, during a system upgrade.
It is better tested than before, because the updates often contain fixes for problems we've identified, fixed and verified. Otherwise we wouldn't be asking for it. It's a bit disheartening when you invest a lot of energy into fixing an important issue and you see people still hitting it because they don't know they should do the update first.

> If someone tells us "don't allow the update until rpm v 5.1 and dnf version 6.2 have been installed -- here's a json file you can auto download for the requirements for each distro upgrade" that's something concrete we can work with. 

I agree that would be great, having a list of NVRs that are known to fix severe upgrade issues. However, that requires a new infrastructure, a new QA workflow, and new code in dnf and gnome-software (probably substantially more code than showing up a banner). I'm not saying we shouldn't do that eventually, but this ticket asks for something that can be done immediately (and helps not just Fedora).
Furthermore, while this list of required NVRs is very nice to have, fully updating the system is still safer. We have automated testing to perform upgrades regularly, but we always do it from a fully updated previous system version. We can't test all combinations of packages the user can have their system in, plus a few selected NVRs from the proposed list. The fully updated system is always the best tested one.

> Something fluffy like "all updates are applied" just isn't precise enough to design for or implement.

If this is too imprecise for you to implement, just let the users choose, for god's sake. Tell them that upgrading a fully updated system is safer. The users will then consider whether they are in a hurry, whether they are bandwidth constrained, and whether they prefer a safer upgrade or not, and act accordingly. All we ask is that you tell them this very obvious piece of information that everyone in QA knows but regular users don't.

I don't really understand why you seemed to be quite OK with this in the beginning of this ticket (you didn't have any objections, just clarifications about UI design), and now you're so negative about this. I'm changing the title to make sure it doesn't give a wrong impression.

> I don't think showing a banner or popping up a dialog is that difficult to do

It's not hard at all, it's just not the right thing to do in my opinion.

> just look whether any updates are known to be available at this very moment

What if there is no cached metadata? For a VM you might install F28 and then immediately upgrade to F29 -- so you never got a chance for the updates to show.

> It is better tested than before

I don't really buy this, sorry. I must be impossible to test all combinations of "old fedora" with the every-changing "latest fedora". When every package is updatable one-by-one you've got a million different ways the system could be updating from x->y. If we know you need rpm >= 1.2.3 for the upgrade to happen then we need to base the design around that information.

> just let the users choose, for god's sake

I don't think that's always the best design, sorry. Either we give the user an upgrade experience that's going to work, or we don't. I also don't know what God has to do with anything.

> why you seemed to be quite OK with this in the beginning

I've never been "OK" with this. It's a workaround.

"When every package is updatable one-by-one you've got a million different ways the system could be updating from x->y."

But the whole idea here is to tell people to update *all the packages* before upgrading. We don't test "all combinations of "old fedora"", no. We *do* test quite often that you can upgrade from the *latest* "old fedora".

> I don't really buy this, sorry. I must be impossible to test all combinations of "old fedora" with the every-changing "latest fedora". When every package is updatable one-by-one you've got a million different ways the system could be updating from x->y. If we know you need rpm >= 1.2.3 for the upgrade to happen then we need to base the design around that information.

We're trying to explain to you that what you request, while helpful, will be less tested and more error-prone, than what we request (everything updated). We make no effort in testing all the combinations, and it's not even possible to do so. We make effort to test latest updates -> N+1. That's a moving target (as everything else suggested in here), but a single state. You, on the other hand, request the combinatorial explosion approach. Even if we specify that rpm 1.2.3 is necessary to fix a severe upgrade bug, we still don't know whether it will work fine with some future dnf released 6 months later (or libdb or whatever). We would have to test not only "latest packages", but also any arbitrary combination of packages with rpm 1.2.3 (the user can install a default system and then only update rpm and nothing else, but she can also update half the system and rpm, etc).

The list of NVRs you request could be used in a different, better way. Rather than request that only these NVRs are up-to-date, the upgrade tool could make a very visible nasty warning that there are known problems in the user's current system and she should by no means attempt to do N+1 upgrade, but do a standard update first, otherwise her system will get horribly broken). So, a nice suggestion by default ("fully updating first is safer!") and an ugly warning if we're sure the current NVRs are not sufficient ("do not upgrade yet or you'll break your system!"). It seemed logical to me to start with the first step first.

> Either we give the user an upgrade experience that's going to work, or we don't.

Let's not fall into talking about software reliability in binary states. What we request here will, I sincerely believe, increase the reliability of the upgrade process (for those that heed the recommendation and perform a full update first).

> What if there is no cached metadata? For a VM you might install F28 and then immediately upgrade to F29 -- so you never got a chance for the updates to show.

Yes, it's always good to plug all the corner cases. But I didn't want to go into these, because I was expecting a negative reaction from you. Even if we cover the 'regular Joe' use case, it's going to be very helpful. If you want to deal with corner cases, it's certainly very welcome. For this particular issue, the solution seems quite simple - if it seems like there are no updates or even metadata, just include a 'Check for updates now' button in the proposed banner. Or perhaps include the button always. The user is informed, it's clear what to do, and now it's his or her choice.

What do we do with this bug if the maintainer disagrees about the correct course of action?

We have two options:
1. Mediate a mutually-acceptable solution
2. Remove this from the Prioritized Bug list and treat it as WONTFIX for that purpose

If there's a way forward that works for everyone, that's my personal preference.

In today's prioritized bugs meeting, we decided to drop the PrioritizedBug label. We don't feel we have the ability to push a resolution on this.

Bug #1804564 is case in point for why we need to apply current release updates before upgrading to the next release. Richard, do you have some way to ensure users are not presented with upgrades to F32 before they have the fix for bug #1804564? We need some mechanism to make sure this works.

I suggested that we only really need to update PackageKit and the dnf stack, but as usual, Kalev is very nervous about possible breakage when applying partial updates like that. So it seems we really do need to update everything. I don't think it's a big deal....

This package has changed maintainer in Fedora. Reassigning to the new maintainer of this component.

This package has changed maintainer in Fedora. Reassigning to the new maintainer of this component.