F20 Self Contained Change: Application Installer

[Jaroslav Reznik]

= Proposed Self Contained Change: Application Installer =
https://fedoraproject.org/wiki/Changes/AppInstaller

Change owner(s): Richard Hughes <rhughes(a)redhat.com&gt;, together with the 
desktop team

We will replace the existing gnome-packagekit frontends (gpk-update-viewer and 
gpk-application) by a new application. 

== Detailed description ==
The current PackageKit frontends are focused on (surprise!) packages.

The new tool, tentatively named gnome-software, is designed from the beginning 
for installing applications. It will present applications with information 
that is relevant to users (screenshots, reviews, descriptions, ratings,...) 
instead of information that is relevant for packagers (dependencies, package 
size, file lists,...).

It will be possible to search and browse for available applications.

gnome-software will also be used to present information about available and 
installed updates. Notifications about available updates will launch gnome-
software if the user chooses to see details. gnome-software will be fully 
integrated with 'offline updates' - if an update includes system packages, it 
will be done as an offline update, regardless whether it gets initiated from the 
gnome-shell menu, a notification, or the gnome-software UI.

To improve some problematic aspects of the updates user experience (long 
waits, locks), we will use the new hawkey backend for PackageKit. 

== Scope ==
Proposal owners:
* Implement minimal required functionality for application installation in 
gnome-software
* Implement minimal required functionality for updates in gnome-software
* Replace gpkg-update-viewer
* Package gnome-software
* Include a hawkey backend in PackageKit and use it 

Other developers:
* Use gnome-software instead of gpk-update-viewer when dealing with updates in 
gnome-settings-daemon, gnome-shell and gnome-control-center 

Release engineering:
* Make metadata available for packaged applications in Fedora (screenshots, 
icons, ratings,...). Not all of this needs to be in place for F20 

Policies and guidelines:
* No immediate changes needed; longer-term, we probably want to make changes 
to way applications are distributed and installed
* The update experience will also benefit from proposed changes to batch 
updates 

_______________________________________________
devel-announce mailing list
devel-announce(a)lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel-announce

[Pete Travis]

On Jul 10, 2013 5:25 AM, "Jaroslav Reznik" <jreznik(a)redhat.com&gt; wrote:
>  = Proposed Self Contained Change: Application Installer =
>  https://fedoraproject.org/wiki/Changes/AppInstaller
>
>  Change owner(s): Richard Hughes <rhughes(a)redhat.com&gt;, together with the
>  desktop team
>
>  We will replace the existing gnome-packagekit frontends 
(gpk-update-viewer and
>  gpk-application) by a new application.
>
>  == Detailed description ==
>  The current PackageKit frontends are focused on (surprise!) packages.
>
>  The new tool, tentatively named gnome-software, is designed from the 
beginning
>  for installing applications. It will present applications with
> information
>  that is relevant to users (screenshots, reviews, descriptions, 
ratings,...)
>  instead of information that is relevant for packagers (dependencies,
package
>  size, file lists,...).
>
>  It will be possible to search and browse for available applications.
>
>  gnome-software will also be used to present information about available 
and
>  installed updates. Notifications about available updates will launch
gnome-
>  software if the user chooses to see details. gnome-software will be
> fully
>  integrated with 'offline updates' - if an update includes system 
packages,
it
>  will be done as an offline update, regardless whether it gets
> initiated 
from the
>  gnome-shell menu, a notification, or the gnome-software UI.
>
>  To improve some problematic aspects of the updates user experience (long
>  waits, locks), we will use the new hawkey backend for PackageKit.
>
>  == Scope ==
>  Proposal owners:
>  * Implement minimal required functionality for application installation in
>  gnome-software
>  * Implement minimal required functionality for updates in gnome-software
>  * Replace gpkg-update-viewer
>  * Package gnome-software
>  * Include a hawkey backend in PackageKit and use it
>
>  Other developers:
>  * Use gnome-software instead of gpk-update-viewer when dealing with 
updates in
>  gnome-settings-daemon, gnome-shell and gnome-control-center
>
>  Release engineering:
>  * Make metadata available for packaged applications in Fedora 
(screenshots,
>  icons, ratings,...). Not all of this needs to be in place for F20
>
>  Policies and guidelines:
>  * No immediate changes needed; longer-term, we probably want to make 
changes
>  to way applications are distributed and installed
>  * The update experience will also benefit from proposed changes to batch
>  updates
>
>  _______________________________________________ 
A few questions:

How does gnome-software differentiate between user facing applications and
other packages, ie back end dependencies, system libraries, texlive
packages? What role do maintainers have in making this distinction, and by
what process?

Where does the additional user facing metadata live? How can maintainers
provide it for their packages, and in what format? Will other packagekit
applications be able to take advantage of it, or just gnome-software?

Thanks,

--Pete

[Bill Nottingham]

Jaroslav Reznik (jreznik(a)redhat.com) said: 
>  = Proposed Self Contained Change: Application Installer =
>  https://fedoraproject.org/wiki/Changes/AppInstaller
>  
>  Change owner(s): Richard Hughes <rhughes(a)redhat.com&gt;, together with the 
>  desktop team
>  
>  We will replace the existing gnome-packagekit frontends (gpk-update-viewer and 
>  gpk-application) by a new application.  
Does this involve large enough of a change to the backend PK APIs that other
PK-using tools (apper, etc.) need to change?

Bill

[Matthias Clasen]

On Wed, 2013-07-10 at 11:12 -0400, Bill Nottingham wrote:
>  Jaroslav Reznik (jreznik(a)redhat.com) said: 
>  > = Proposed Self Contained Change: Application Installer =
>  > https://fedoraproject.org/wiki/Changes/AppInstaller
>  > 
>  > Change owner(s): Richard Hughes <rhughes(a)redhat.com&gt;, together with the 
>  > desktop team
>  > 
>  > We will replace the existing gnome-packagekit frontends (gpk-update-viewer and 
>  > gpk-application) by a new application. 
>  
>  Does this involve large enough of a change to the backend PK APIs that other
>  PK-using tools (apper, etc.) need to change? 
(Richard is on vacation this week, I'll try to answer as well as I can)

> From my understanding, it does not necessarily involve any change of
> PK 
backend apis. Although we may need some new apis related to metadata.
I'll ask Richard to flesh out that part of the change page when he's
back.

[Kevin Fenzi]

On Wed, 10 Jul 2013 13:02:24 +0200
Jaroslav Reznik <jreznik(a)redhat.com&gt; wrote:

>  = Proposed Self Contained Change: Application Installer =
>  https://fedoraproject.org/wiki/Changes/AppInstaller
>  
>  Change owner(s): Richard Hughes <rhughes(a)redhat.com&gt;, together with
>  the desktop team
>  
>  We will replace the existing gnome-packagekit frontends
>  (gpk-update-viewer and gpk-application) by a new application.  
Would there be any value in keeping those around for a cycle or so for
folks that prefer package centric updates? Or better to just ask them
to move to yum/yumex/apper now?

...snip...

>  To improve some problematic aspects of the updates user experience
>  (long waits, locks), we will use the new hawkey backend for
>  PackageKit.  
(echo issue with a different backend that Toshio had)
 
>  == Scope ==
>  Proposal owners:
>  * Implement minimal required functionality for application
>  installation in gnome-software
>  * Implement minimal required functionality for updates in
>  gnome-software
>  * Replace gpkg-update-viewer
>  * Package gnome-software
>  * Include a hawkey backend in PackageKit and use it 
>  
>  Other developers:
>  * Use gnome-software instead of gpk-update-viewer when dealing with
>  updates in gnome-settings-daemon, gnome-shell and
>  gnome-control-center  
I'm assuming this will be desktop/gnome centric? Or would it all just
work in Xfce/LXDE/ratpoision sessions?
 
>  Release engineering:
>  * Make metadata available for packaged applications in Fedora
>  (screenshots, icons, ratings,...). Not all of this needs to be in
>  place for F20  
Can you expand on these exact needs? What exactly is required for f20? 
What is post f20? 
 
>  Policies and guidelines:
>  * No immediate changes needed; longer-term, we probably want to make
>  changes to way applications are distributed and installed 
Can you expand on that? In what way?

>  * The update experience will also benefit from proposed changes to
>  batch updates  
Is that part of this proposal? Or something else?

kevin

[Matthias Clasen]

On Wed, 2013-07-10 at 09:51 -0600, Kevin Fenzi wrote:
>  On Wed, 10 Jul 2013 13:02:24 +0200
>  Jaroslav Reznik <jreznik(a)redhat.com&gt; wrote:
>  
>  > = Proposed Self Contained Change: Application Installer =
>  > https://fedoraproject.org/wiki/Changes/AppInstaller
>  > 
>  > Change owner(s): Richard Hughes <rhughes(a)redhat.com&gt;, together with
>  > the desktop team
>  > 
>  > We will replace the existing gnome-packagekit frontends
>  > (gpk-update-viewer and gpk-application) by a new application. 
>  
>  Would there be any value in keeping those around for a cycle or so for
>  folks that prefer package centric updates? Or better to just ask them
>  to move to yum/yumex/apper now? 
I don't anticipate removing those tools in the short term - 'replace'
really means 'in the default install' and 'wrt to desktop integration'.

[Adam Williamson]

On Wed, 2013-07-10 at 09:51 -0600, Kevin Fenzi wrote:
>  On Wed, 10 Jul 2013 13:02:24 +0200
>  Jaroslav Reznik <jreznik(a)redhat.com&gt; wrote:
>  
>  > = Proposed Self Contained Change: Application Installer =
>  > https://fedoraproject.org/wiki/Changes/AppInstaller
>  > 
>  > Change owner(s): Richard Hughes <rhughes(a)redhat.com&gt;, together with
>  > the desktop team
>  > 
>  > We will replace the existing gnome-packagekit frontends
>  > (gpk-update-viewer and gpk-application) by a new application. 
>  
>  Would there be any value in keeping those around for a cycle or so for
>  folks that prefer package centric updates? Or better to just ask them
>  to move to yum/yumex/apper now? 
FWIW, everyone seems to hate gpk-application, so I doubt anyone would
shed any tears over its loss. =) And if gpk-update-viewer has any
committed fans, I ain't met 'em.

>  > Other developers:
>  > * Use gnome-software instead of gpk-update-viewer when dealing with
>  > updates in gnome-settings-daemon, gnome-shell and
>  > gnome-control-center 
>  
>  I'm assuming this will be desktop/gnome centric? Or would it all just
>  work in Xfce/LXDE/ratpoision sessions? 
That's all GNOME-specific stuff, as I read it. None of this feature
looks like it particularly applies to other desktops.
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora
http://www.happyassassin.net

[Jiri Eischmann]

Adam Williamson píše v St 10. 07. 2013 v 14:35 -0700:
>  On Wed, 2013-07-10 at 09:51 -0600, Kevin Fenzi wrote:
>  > On Wed, 10 Jul 2013 13:02:24 +0200
>  > Jaroslav Reznik <jreznik(a)redhat.com&gt; wrote:
>  > 
>  > > = Proposed Self Contained Change: Application Installer =
>  > > https://fedoraproject.org/wiki/Changes/AppInstaller
>  > > 
>  > > Change owner(s): Richard Hughes <rhughes(a)redhat.com&gt;, together with
>  > > the desktop team
>  > > 
>  > > We will replace the existing gnome-packagekit frontends
>  > > (gpk-update-viewer and gpk-application) by a new application. 
>  > 
>  > Would there be any value in keeping those around for a cycle or so for
>  > folks that prefer package centric updates? Or better to just ask them
>  > to move to yum/yumex/apper now?
>  
>  FWIW, everyone seems to hate gpk-application, so I doubt anyone would
>  shed any tears over its loss. =) And if gpk-update-viewer has any
>  committed fans, I ain't met 'em. 
And AFAIK Yumex is still maintained and in Fedora repositories and IMHO
does the job better than gnome-packagekit. So I wouldn't worry about
getting rid of it completely either.

Jiri

[Miloslav Trmač]

> > = Proposed Self Contained Change: Application Installer =
> > https://fedoraproject.org/wiki/Changes/AppInstaller 
> > To improve some problematic aspects of the updates user
> experience
> > (long waits, locks), we will use the new hawkey backend for
> > PackageKit.
>  (echo issue with a different backend that Toshio had) 
I haven't seen Toshio's mail, so I apologize for possible redundancy:

> From an earlier FESCo decision
https://fedorahosted.org/fesco/ticket/669#comment:24 :
>  The RPM package installation GUI that is installed by default should
> use the same dependency solver/backend as the non-GUI default. 
Is this Change implicitly asking FESCo to revoke this requirement?
    Mirek

[Matthias Clasen]

On Thu, 2013-07-11 at 16:38 +0200, Miloslav Trmač wrote:
>  >> = Proposed Self Contained Change: Application Installer =
>  >> https://fedoraproject.org/wiki/Changes/AppInstaller
>  
>  >> To improve some problematic aspects of the updates user experience
>  >> (long waits, locks), we will use the new hawkey backend for
>  >> PackageKit.
>  > (echo issue with a different backend that Toshio had)
>  
>  I haven't seen Toshio's mail, so I apologize for possible redundancy:
>  
>  From an earlier FESCo decision
>  https://fedorahosted.org/fesco/ticket/669#comment:24 :
>  > The RPM package installation GUI that is installed by default should use the same
> dependency solver/backend as the non-GUI default.
>  
>  Is this Change implicitly asking FESCo to revoke this requirement? 
Yes, if you want to put it that way. We want to use a backend that can
supported the desired user experience.

The hawkey stack is groomed to replace yum anyway. All we're asking is
that we can use it early, so we can provide the testing exposure they
need and ensure that hawkey does actually support the things we need.

Without that, there's a very real danger that hawkey/dnf end up
producing a perfect copy of yum (including all of the problems)...

[Jan Zelený]

On 11. 7. 2013 at 12:59:42, Matthias Clasen wrote:
>  On Thu, 2013-07-11 at 16:38 +0200, Miloslav Trmač wrote:
>  > >> = Proposed Self Contained Change: Application Installer =
>  > >> https://fedoraproject.org/wiki/Changes/AppInstaller
>  > >> 
>  > >> To improve some problematic aspects of the updates user experience
>  > >> (long waits, locks), we will use the new hawkey backend for
>  > >> PackageKit.
>  > > 
>  > > (echo issue with a different backend that Toshio had)
>  > 
>  > I haven't seen Toshio's mail, so I apologize for possible redundancy:
>  > 
>  > From an earlier FESCo decision
>  > 
>  > https://fedorahosted.org/fesco/ticket/669#comment:24 :
>  > > The RPM package installation GUI that is installed by default should use
>  > > the same dependency solver/backend as the non-GUI default.> 
>  > Is this Change implicitly asking FESCo to revoke this requirement?
>  
>  Yes, if you want to put it that way. We want to use a backend that can
>  supported the desired user experience.
>  
>  The hawkey stack is groomed to replace yum anyway. All we're asking is
>  that we can use it early, so we can provide the testing exposure they
>  need and ensure that hawkey does actually support the things we need.
>  
>  Without that, there's a very real danger that hawkey/dnf end up
>  producing a perfect copy of yum (including all of the problems)... 
Don't worry, that's not gonna happen. Hawkey has been built on top of libsolv 
library that implements a different solver than yum uses. Under no 
circumstances will this change. The more likely scenario is that gnome-
software/PackageKit will be forced by the policy to use the old yum which will 
make future adoption of dnf much more difficult.

Thanks
Jan

[Jaroslav Reznik]

----- Original Message -----
>  > Yes, if you want to put it that way. We want to use a backend
> that can
>  > supported the desired user experience.
>  > 
>  > The hawkey stack is groomed to replace yum anyway. All we're asking is
>  > that we can use it early, so we can provide the testing exposure they
>  > need and ensure that hawkey does actually support the things we need.
>  > 
>  > Without that, there's a very real danger that hawkey/dnf end up
>  > producing a perfect copy of yum (including all of the problems)...
>  
>  Don't worry, that's not gonna happen. Hawkey has been built on top of libsolv
>  library that implements a different solver than yum uses. Under no
>  circumstances will this change. The more likely scenario is that gnome-
>  software/PackageKit will be forced by the policy to use the old yum which
>  will
>  make future adoption of dnf much more difficult. 
So, do I understand you correctly that you as Yum/Dnf guys would be ok to
have a different backend for GUI and non-GUI use cases as mentioned in
this thread and agreed by FESCo previously? I'd be more than happy to
see your sign off for this change and state this too there.

Jaroslav

>  Thanks
>  Jan
>  --
>  devel mailing list
>  devel(a)lists.fedoraproject.org
>  https://admin.fedoraproject.org/mailman/listinfo/devel

[Jan Zelený]

On 15. 7. 2013 at 07:47:06, Jaroslav Reznik wrote:
>  ----- Original Message -----
>  
>  > > Yes, if you want to put it that way. We want to use a backend that can
>  > > supported the desired user experience.
>  > > 
>  > > The hawkey stack is groomed to replace yum anyway. All we're asking is
>  > > that we can use it early, so we can provide the testing exposure they
>  > > need and ensure that hawkey does actually support the things we need.
>  > > 
>  > > Without that, there's a very real danger that hawkey/dnf end up
>  > > producing a perfect copy of yum (including all of the problems)...
>  > 
>  > Don't worry, that's not gonna happen. Hawkey has been built on top of
>  > libsolv library that implements a different solver than yum uses. Under
>  > no circumstances will this change. The more likely scenario is that
>  > gnome- software/PackageKit will be forced by the policy to use the old
>  > yum which will
>  > make future adoption of dnf much more difficult.
>  
>  So, do I understand you correctly that you as Yum/Dnf guys would be ok to
>  have a different backend for GUI and non-GUI use cases as mentioned in
>  this thread and agreed by FESCo previously? I'd be more than happy to
>  see your sign off for this change and state this too there. 
Well, it's a bit more complicated than that. Obviously there would be a 
"problem" with both programs offering different combinations of packages in some

cases. But combined with the fact that the use case/target group of users 
(applications vs. packages) is different for both, I don't think it would be 
that much of an issue.

Back to my original comment, switching your SW Management application is a 
painful process and I seriously doubt it can be done completely at once - 
consider depending pieces like plugins, Anaconda and PK. Therefore I was 
hoping for incremental adoption where possible. With that in mind, the optimal 
solution from my perspective would be to implement hawkey backend in PK and 
let it coexist with current yum backend until yum is replaced by dnf. Another 
option would be to make the new PK (or just the backend if possible) optional 
for now and make it default together with dnf replacing yum. However I 
strongly suspect that neither of these two proposals are acceptable for 
Richard.

Thoughts?

Thanks
Jan

[Kamil Paral]

>  > So, do I understand you correctly that you as Yum/Dnf guys would
> be ok to
>  > have a different backend for GUI and non-GUI use cases as mentioned in
>  > this thread and agreed by FESCo previously? I'd be more than happy to
>  > see your sign off for this change and state this too there.
>  
>  Well, it's a bit more complicated than that. Obviously there would be a
>  "problem" with both programs offering different combinations of packages in
>  some
>  cases. But combined with the fact that the use case/target group of users
>  (applications vs. packages) is different for both, I don't think it would be
>  that much of an issue. 
Wouldn't it be easier to keep gpk-application and gpk-update-viewer installed and set
as default applications, and provide AppInstaller as an alternative, experimental program
(also installed by default, perhaps)? In F20 conservative users could continue using gpk-*
and interested users could start playing with AppInstaller. In F21 AppInstaller can be
deemed stable and gpk-* can be removed from the default install.

[drago01]

On Fri, Jul 19, 2013 at 1:02 PM, Kamil Paral <kparal(a)redhat.com&gt; wrote:
> > > So, do I understand you correctly that you as Yum/Dnf guys
> would be ok to
> > > have a different backend for GUI and non-GUI use cases as mentioned in
> > > this thread and agreed by FESCo previously? I'd be more than happy to
> > > see your sign off for this change and state this too there.
> >
> > Well, it's a bit more complicated than that. Obviously there would be a
> > "problem" with both programs offering different combinations of packages
> in
> > some
> > cases. But combined with the fact that the use case/target group of users
> > (applications vs. packages) is different for both, I don't think it would be
> > that much of an issue.
>
>  Wouldn't it be easier to keep gpk-application and gpk-update-viewer installed and set
> as default applications, and provide AppInstaller as an alternative, experimental program
> (also installed by default, perhaps)? In F20 conservative users could continue using gpk-*
> and interested users could start playing with AppInstaller. In F21 AppInstaller can be
> deemed stable and gpk-* can be removed from the default install. 
No .. having two completely different user interfaces / experiences
for the same thing does not make much sense.

[Matthias Clasen]

On Fri, 2013-07-19 at 07:02 -0400, Kamil Paral wrote:
>  > > So, do I understand you correctly that you as Yum/Dnf guys
> would be ok to
>  > > have a different backend for GUI and non-GUI use cases as mentioned in
>  > > this thread and agreed by FESCo previously? I'd be more than happy to
>  > > see your sign off for this change and state this too there.
>  > 
>  > Well, it's a bit more complicated than that. Obviously there would be a
>  > "problem" with both programs offering different combinations of packages
> in
>  > some
>  > cases. But combined with the fact that the use case/target group of users
>  > (applications vs. packages) is different for both, I don't think it would be
>  > that much of an issue.
>  
>  Wouldn't it be easier to keep gpk-application and gpk-update-viewer installed and set
> as default applications, and provide AppInstaller as an alternative, experimental program
> (also installed by default, perhaps)? In F20 conservative users could continue using gpk-*
> and interested users could start playing with AppInstaller. In F21 AppInstaller can be
> deemed stable and gpk-* can be removed from the default install. 
This is the contingency plan. Depending on how far we get with the new
application, it may well be enacted - the goals are pretty ambitious...

[Adam Williamson]

On Fri, 2013-07-19 at 07:02 -0400, Kamil Paral wrote:
>  > > So, do I understand you correctly that you as Yum/Dnf guys
> would be ok to
>  > > have a different backend for GUI and non-GUI use cases as mentioned in
>  > > this thread and agreed by FESCo previously? I'd be more than happy to
>  > > see your sign off for this change and state this too there.
>  > 
>  > Well, it's a bit more complicated than that. Obviously there would be a
>  > "problem" with both programs offering different combinations of packages
> in
>  > some
>  > cases. But combined with the fact that the use case/target group of users
>  > (applications vs. packages) is different for both, I don't think it would be
>  > that much of an issue.
>  
>  Wouldn't it be easier to keep gpk-application and gpk-update-viewer
>  installed and set as default applications, and provide AppInstaller as
>  an alternative, experimental program (also installed by default,
>  perhaps)?  
It might be easier, but it'd probably suck more. gpk-application is
pretty crappy, let's face it. It looks pretty bad if you compare it with
just about any other distro's graphical package/app manager tools. This
is something we are regularly dinged on in reviews. IMHO the sooner we
replace it with something better, the...better.

(And I'd hate to go another release without resolving
https://bugzilla.redhat.com/show_bug.cgi?id=863592 , just to bang that
drum again).
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora
http://www.happyassassin.net

[Richard Hughes]

On 15 July 2013 16:07, Jan Zelený <jzeleny(a)redhat.com&gt; wrote:
>  Another
>  option would be to make the new PK (or just the backend if possible) optional
>  for now and make it default together with dnf replacing yum. However I
>  strongly suspect that neither of these two proposals are acceptable for
>  Richard. 
Well, although gnome-software works with the yum backend, it performs
very badly and the UX is terrible. I'm not sure I'd want
gnome-software by default with yum as a backend.

Richard

[Toshio Kuratomi]

On Thu, Jul 11, 2013 at 7:38 AM, Miloslav Trmač <mitr(a)volny.cz&gt; wrote:
>  I haven't seen Toshio's mail, so I apologize for possible
> redundancy:
>  
Yeah, sorry, I got caught in the replying-to-docs-list trap.  here's
what I had written (mostly the same as you but I also flagged things
that I thought could push this into system-wide change territory):

On Wed, Jul 10, 2013 at 01:02:24PM +0200, Jaroslav Reznik wrote:
>  * Replace gpkg-update-viewer
>  * Include a hawkey backend in PackageKit and use it
>  
These two in combination make this a system-wide change.  Current policy is
that:

"The RPM package installation GUI that is installed by default should use
the same dependency solver/backend as the non-GUI default."

https://fedorahosted.org/fesco/ticket/669#comment:24

So we'd need to move to hawkey for the non-GUI default as well.  Is the
packaging team ready to make that shift for F20?

A shift to replace (as opposed to supplementing) a package-centric view to
an application-centric view might also be a system-wide change.  I think
I incline towards this still being a self-contained change as the non-GUI
offering will continue to be package-centric (so it's supplementing) but
I could be convinced otherwise.

-Toshio

[Jan Zelený]

On 12. 7. 2013 at 11:33:19, Toshio Kuratomi wrote:
>  On Thu, Jul 11, 2013 at 7:38 AM, Miloslav Trmač <mitr(a)volny.cz&gt;
> wrote:
>  > I haven't seen Toshio's mail, so I apologize for possible redundancy:
>  Yeah, sorry, I got caught in the replying-to-docs-list trap.  here's
>  what I had written (mostly the same as you but I also flagged things
>  that I thought could push this into system-wide change territory):
>  
>  On Wed, Jul 10, 2013 at 01:02:24PM +0200, Jaroslav Reznik wrote:
>  > * Replace gpkg-update-viewer
>  > * Include a hawkey backend in PackageKit and use it
>  
>  These two in combination make this a system-wide change.  Current policy is
>  that:
>  
>  "The RPM package installation GUI that is installed by default should use
>  the same dependency solver/backend as the non-GUI default."
>  
>  https://fedorahosted.org/fesco/ticket/669#comment:24
>  
>  So we'd need to move to hawkey for the non-GUI default as well.  Is the
>  packaging team ready to make that shift for F20? 
No, there is still at least several months of intensive work ahead of us if we 
don't want the shift to end up as an epic fail.

>  A shift to replace (as opposed to supplementing) a package-centric
> view to
>  an application-centric view might also be a system-wide change.  I think
>  I incline towards this still being a self-contained change as the non-GUI
>  offering will continue to be package-centric (so it's supplementing) but
>  I could be convinced otherwise. 
Thanks
Jan

[Adam Williamson]

On Wed, 2013-07-10 at 13:02 +0200, Jaroslav Reznik wrote:
>  = Proposed Self Contained Change: Application Installer =
>  https://fedoraproject.org/wiki/Changes/AppInstaller
>  
>  Change owner(s): Richard Hughes <rhughes(a)redhat.com&gt;, together with the 
>  desktop team
>  
>  We will replace the existing gnome-packagekit frontends (gpk-update-viewer and 
>  gpk-application) by a new application.  
Yay!

>  == Detailed description ==
>  The current PackageKit frontends are focused on (surprise!) packages.
>  
>  The new tool, tentatively named gnome-software, is designed from the beginning 
>  for installing applications. It will present applications with information 
>  that is relevant to users (screenshots, reviews, descriptions, ratings,...) 
>  instead of information that is relevant for packagers (dependencies, package 
>  size, file lists,...).
>  
>  It will be possible to search and browse for available applications.
>  
>  gnome-software will also be used to present information about available and 
>  installed updates. Notifications about available updates will launch gnome-
>  software if the user chooses to see details. gnome-software will be fully 
>  integrated with 'offline updates' - if an update includes system packages, it 
>  will be done as an offline update, regardless whether it gets initiated from the 
>  gnome-shell menu, a notification, or the gnome-software UI. 
This sounds like a nice plan and will finally resolve
https://bugzilla.redhat.com/show_bug.cgi?id=863592 . I'd just like to
note that at present our release requirements are basically that the
'official' update methods have to work at Alpha:

"The installed system must be able to download and install updates with
yum and with the default graphical package manager in all
release-blocking desktops."

https://fedoraproject.org/wiki/Fedora_20_Alpha_Release_Criteria#Updates

Is the planned development timeframe for this Change such that we can
expect this requirement to be satisfied?

Note that update notification is required to work starting from Beta
rather than Alpha:

"Release-blocking desktops must notify the user of available updates,
but must not do so when running as a live image."

https://fedoraproject.org/wiki/Fedora_20_Beta_Release_Criteria#Update_not...

>  Other developers:
>  * Use gnome-software instead of gpk-update-viewer when dealing with updates in 
>  gnome-settings-daemon, gnome-shell and gnome-control-center  
We really need to ensure the necessary co-ordination is done so that
this happens, and the online/offline update mess is cleared up for F20
Alpha.

>  Policies and guidelines:
>  * No immediate changes needed; longer-term, we probably want to make changes 
>  to way applications are distributed and installed
>  * The update experience will also benefit from proposed changes to batch 
>  updates  
* The release criterion may need to be reworded, depending on whether
the concept of "download and install updates with the default graphical
package manager" really applies to the design.
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora
http://www.happyassassin.net

[Miloslav Trmač]

On Wed, Jul 10, 2013 at 1:02 PM, Jaroslav Reznik <jreznik(a)redhat.com&gt; wrote:
>  = Proposed Self Contained Change: Application Installer =
>  https://fedoraproject.org/wiki/Changes/AppInstaller
>  
>  == Scope ==
>  Other developers:
>  * Use gnome-software instead of gpk-update-viewer when dealing with updates in
>  gnome-settings-daemon, gnome-shell and gnome-control-center
>
>  Release engineering:
>  * Make metadata available for packaged applications in Fedora (screenshots,
>  icons, ratings,...). Not all of this needs to be in place for F20
>
>  Policies and guidelines:
>  * No immediate changes needed; longer-term, we probably want to make changes
>  to way applications are distributed and installed
>  * The update experience will also benefit from proposed changes to batch
>  updates 
(There's a first time for everything...)
<FESCo>
This Change affects other parts of the distribution (rel-eng,
policies?) and should therefore be treated as a "system-wide change",
not "self-contained".
</FESCo>
    Mirek

[Bill Nottingham]

Miloslav Trmač (mitr(a)volny.cz) said: 
>  > Release engineering:
>  > * Make metadata available for packaged applications in Fedora (screenshots,
>  > icons, ratings,...). Not all of this needs to be in place for F20
>  >
>  > Policies and guidelines:
>  > * No immediate changes needed; longer-term, we probably want to make changes
>  > to way applications are distributed and installed
>  > * The update experience will also benefit from proposed changes to batch
>  > updates
>  
>  (There's a first time for everything...)
>  <FESCo>
>  This Change affects other parts of the distribution (rel-eng,
>  policies?) and should therefore be treated as a "system-wide change",
>  not "self-contained".
>  </FESCo> 
Yeah, the releng changes probably make it better described as a system-wide
change, even though it's only visible to the user as a self-contained one.

Bill

[Matthias Clasen]

On Thu, 2013-07-11 at 16:46 +0200, Miloslav Trmač wrote:

>  >
>  > Policies and guidelines:
>  > * No immediate changes needed; longer-term, we probably want to make changes
>  > to way applications are distributed and installed
>  > * The update experience will also benefit from proposed changes to batch
>  > updates
>  
>  (There's a first time for everything...)
>  <FESCo>
>  This Change affects other parts of the distribution (rel-eng,
>  policies?) and should therefore be treated as a "system-wide change",
>  not "self-contained".
>  </FESCo> 
Could go either way on this. The application itself will be fairly
self-contained. You are correct that there are changes to other parts of
the distribution involved here. Some are more or less independent
(batching updates), others are hard requirements (additional metadata)
to implement the desired UX.

I'll change this to 'system-wide' next week, after discussing some of
the details with Richard.