Matt, are you actually using a graphical update tool ? I would expect that most people who get upset by the need to reboot are using yum on the commandline anyway.

Also, what is the outcome that you expect here ? rewrite gnome-software ? go back to gpk-update-viewer ? something else ?

I don't think it is fesco's role to second-guess application design.

Finally, Matt, I would have really appreciated if you had reached out to the relevant people who are involved in the design and implementation choices related to this, before filing a fesco ticket.

Is this behaviour a bug (all updates as opposed to the previous 'OS components')? If it's a bug will it be fixed in time for F20?

toshio: offline updates never made a distinction between whether the update was for the OS.

In the past, different GUIs offered update methods. gpk-update-viewer triggered an online update. gnome-shell notifications, on the other hand, would offer to do the update offline. This inconsistency was pretty bad - it left users unsure about which was the "correct" way to update.

For F20 the only difference is that we are now being consistent about offering offline updates (something that we have been doing since at least F19).

Installing updates through the command line will work in the same way that it always has done.

The AppInstaller implementation differs significantly from the approved Change plan.

Whether or not this is a desirable or acceptable alteration is a second, separate issue. That should have been brought to the Feature Wrangler and then to FESCo.

FESCo is the technical steering committee for Fedora and this is absolutely within our purview. I expect we will ask the change owners to come up with a way to meet the approved plan or activate the contingency plan.

Replying to [comment:7 mattdm]:

The AppInstaller implementation differs significantly from the approved Change plan.

Whether or not this is a desirable or acceptable alteration is a second, separate issue. That should have been brought to the Feature Wrangler and then to FESCo.

FESCo is the technical steering committee for Fedora and this is absolutely within our purview. I expect we will ask the change owners to come up with a way to meet the approved plan or activate the contingency plan.

This is not a contracting situation, and we are not contractually obligated to stick to the letter of the feature page. It is a misunderstanding of the way application design and development works to think that we could write a one-page feature description and then have it implemented point-by-point. If that is how you expect feature work in fedora to happen, I'd rather take it out of fedora altogether.

Replying to [comment:8 mclasen]:

This is not a contracting situation, and we are not contractually obligated to stick to the letter of the feature page.

(What is then, in your opinion, the purpose of every individual letter on the Change page, if not to communicate the agreed plan? And what value does the agreed plan have it is not adhered to?)

Replying to [comment:7 mattdm]:

The AppInstaller implementation differs significantly from the approved Change plan.

Actually the page as has been approved says

For F20, we will focus on completing the offline update experience and use gnome-software for it instead of gpk-update-viewer.
which, by my reading, is a really (unacceptably?) convoluted way of saying that this has been the plan from the start, and has been approved as such.

Replying to [comment:7 mattdm]:

I expect we will ask the change owners to come up with a way to meet the approved plan or activate the contingency plan.

You intend to throw out a desperately needed feature on the grounds of bureaucratic correctness?

You haven't even said what your concerns are, or spoken to the developers and designers involved about what we have done and why.

You should realize that the update ui in gnome-shell in f19 already only offers you to install updates on reboot. Granted, you can use gpk-update-viewer to have a 'graphical' way to pick-and-choose updates without reboot, but that is still there in f20.

Replying to [comment:11 aday]:

You intend to throw out a desperately needed feature on the grounds of bureaucratic correctness?

I don't intend to throw anything. I said that we "''should talk about it''". I'm frankly puzzled by the aggressive responses here.

You haven't even said what your concerns are, or spoken to the developers and designers involved about what we have done and why.

Again, that's a second, separate issue. I'd be happy to discuss it, once we're at that point, but clearly we have a first problem to deal with.

mclasen: I'm not sure your description of F19 is correct. IIRC, this is the state of F19:

• Update notifications come from gpk-update-viewer by default, and trigger an online update via gpk-update-viewer
• gpk-update-viewer is what you get if you open the overview and type 'Update' -> online update
• When PK is aware there are updates available, there is an 'Install updates and restart' entry in the User menu, which triggers an offline update

i.e. both online and offline update mechanisms are available, with no clear messaging as to which is preferred, and no kind of 'online for apps, offline for system' split.

In F20 as it stands, graphical online updates have been completely taken out by default (gpk-update-viewer is no longer installed by default, and GNOME Software handles update notifications), and all mechanisms you can find (notifications, user menu, GNOME Software) lead to an offline update in all cases. This is clearly much more consistent and less confusing, which is a win, but it also clearly does not line up with the Change as it was proposed to, discussed and approved by FESCo.

On a practical basis it seems we have only two choices here: go back to the pre-F18 state of online updates for everything, or roll over with the new 'offline updates for everything' upstream GNOME plan, as I don't think the FESCo tail can wag the GNOME dog into implementing its initial plan. Going back to the F18/F19 state of affairs where we had a confused mess of update methods would be a bad outcome for everyone, I think, and we should definitely strive to avoid that.

Replying to [comment:13 mattdm]:

You intend to throw out a desperately needed feature on the grounds of bureaucratic correctness?

I don't intend to throw anything. I said that we "''should talk about it''".

You said:

"I expect we will ask the change owners to come up with a way to meet the approved plan or activate the contingency plan."

The contingency plan in this case is not to use GNOME Software in F20. Your statement equates to "you either have to exactly conform to the original feature description [1] or GNOME Software will not be included in F20."

We worked extremely hard to get Software ready for F20 (I know that evenings and weekends were spent on the project). That additional effort would essentially be discarded (for no good reason) if the contingency plan is activated.

I'm frankly puzzled by the aggressive responses here.

You are not the only one who is puzzled. I'd be happy to explain my perspective if that would help.

[1] Something which is technically impossible in my opinion.

Two things were approved:

info mitr's proposal to update change policy passed (+1:5, 0:0, -1:1)

Text of the update follows:

"""

Change owners are trusted '''and depended upon''' to highlight all relevant changes. Not noting important changes(whether due to oversight, different opinion of importance, or intentionally) breaks the Change process.

"""

@mitr, could you take care of that?

Second Proposal was:

info Proposal to Keep F20 behavior as-is (all offline updates for gnome). Update Change page to reflect current implementation, update docs and release notes to match. Passed (+1:5, 0:2, -1:0)

@rhughes or @mclasen could you take care of that?

One more thing that we will have to discuss at some point is the acceptable frequency of updates. According to Matthias:

The logic I recently implemented for gnome-software 3.12 in F21 is to
check for new updates once per day, and download updates when they are
important (e.g. security updates), or when it has been a week since the
last time we installed updates. When a consistent set of updates has
been downloaded, we notify the user about available updates.

https://lists.fedoraproject.org/pipermail/devel/2013-November/191177.html

I'm concerned that due to the frequency of "important" (security) updates in Fedora, we'll be prompting users to reboot every day or two. I do not believe that's a reasonable default behavior.

1) With the product split, I'm not sure that's necessary to worry about right now.
2) In any case, there is a push for some of the products, at least, to be batching updates in general.

Replying to [comment:17 catanzaro]:

I'm concerned that due to the frequency of "important" (security) updates in Fedora, we'll be prompting users to reboot every day or two. I do not believe that's a reasonable default behavior.

This is one of my concerns too. As I understand the implementation, the current approach is to not even alert for updates very often, so this is better.

If someone could update the change page to reflect how things are currently that would be great.

ACTION: mattdm will contact the Change owner to update the wiki page and release notes (mmaslano, 18:09:08)

• 1193 reboots for all updates -- are we ready for this? (sgallagh,

  
  18:03:39)
• ACTION: nirik to update the AppInstaller Change pages (sgallagh,
  18:05:48)

I have updated the wiki page to reflect what I know of this change in f20. Further changes/clarifications welcome there.