Pretty much what we discussed on IRC yesterday. Anyone have problems with me committing this today?
josh
diff --git a/gnome-shell.spec b/gnome-shell.spec index a085076..94e284d 100644 --- a/gnome-shell.spec +++ b/gnome-shell.spec @@ -102,8 +102,6 @@ Requires: gdm-libs%{?_isa} Requires: clutter%{?_isa} >= %{clutter_version} # needed for settings items in menus Requires: control-center -# needed for captive portal support -Requires: NetworkManager-config-connectivity-fedora
%description GNOME Shell provides core user interface functions for the GNOME 3 desktop, diff --git a/fedora-release.spec b/fedora-release.spec index 333875f..1d7db6b 100644 --- a/fedora-release.spec +++ b/fedora-release.spec @@ -72,6 +72,8 @@ Requires: fedora-release = %{version}-%{release} Conflicts: fedora-release-cloud Conflicts: fedora-release-server Conflicts: fedora-release-standard +# needed for captive portal support +Requires: NetworkManager-config-connectivity-fedora
%description workstation Provides a base package for Fedora Workstation-specific configuration files to
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Tue, 30 Sep 2014 12:49:43 -0400 Josh Boyer jwboyer@fedoraproject.org wrote:
Pretty much what we discussed on IRC yesterday. Anyone have problems with me committing this today?
josh
diff --git a/gnome-shell.spec b/gnome-shell.spec index a085076..94e284d 100644 --- a/gnome-shell.spec +++ b/gnome-shell.spec @@ -102,8 +102,6 @@ Requires: gdm-libs%{?_isa} Requires: clutter%{?_isa} >= %{clutter_version} # needed for settings items in menus Requires: control-center -# needed for captive portal support -Requires: NetworkManager-config-connectivity-fedora
%description GNOME Shell provides core user interface functions for the GNOME 3 desktop, diff --git a/fedora-release.spec b/fedora-release.spec index 333875f..1d7db6b 100644 --- a/fedora-release.spec +++ b/fedora-release.spec @@ -72,6 +72,8 @@ Requires: fedora-release = %{version}-%{release} Conflicts: fedora-release-cloud Conflicts: fedora-release-server Conflicts: fedora-release-standard +# needed for captive portal support +Requires: NetworkManager-config-connectivity-fedora
%description workstation Provides a base package for Fedora Workstation-specific configuration files to
please use git send-email and send me patches from the repo at git://git.fedorahosted.org/git/fedora-release.git/ for both f21 and master branches for fedora-release changes please.
Thanks
Dennis
On Tue, Sep 30, 2014 at 1:41 PM, Dennis Gilmore dennis@ausil.us wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Tue, 30 Sep 2014 12:49:43 -0400 Josh Boyer jwboyer@fedoraproject.org wrote:
Pretty much what we discussed on IRC yesterday. Anyone have problems with me committing this today?
josh
diff --git a/gnome-shell.spec b/gnome-shell.spec index a085076..94e284d 100644 --- a/gnome-shell.spec +++ b/gnome-shell.spec @@ -102,8 +102,6 @@ Requires: gdm-libs%{?_isa} Requires: clutter%{?_isa} >= %{clutter_version} # needed for settings items in menus Requires: control-center -# needed for captive portal support -Requires: NetworkManager-config-connectivity-fedora
%description GNOME Shell provides core user interface functions for the GNOME 3 desktop, diff --git a/fedora-release.spec b/fedora-release.spec index 333875f..1d7db6b 100644 --- a/fedora-release.spec +++ b/fedora-release.spec @@ -72,6 +72,8 @@ Requires: fedora-release = %{version}-%{release} Conflicts: fedora-release-cloud Conflicts: fedora-release-server Conflicts: fedora-release-standard +# needed for captive portal support +Requires: NetworkManager-config-connectivity-fedora
%description workstation Provides a base package for Fedora Workstation-specific configuration files to
please use git send-email and send me patches from the repo at git://git.fedorahosted.org/git/fedora-release.git/ for both f21 and master branches for fedora-release changes please.
Um... ok. Or I could just commit them... is there a problem with me doing that?
josh
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Tue, 30 Sep 2014 14:10:24 -0400 Josh Boyer jwboyer@fedoraproject.org wrote:
On Tue, Sep 30, 2014 at 1:41 PM, Dennis Gilmore dennis@ausil.us wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Tue, 30 Sep 2014 12:49:43 -0400 Josh Boyer jwboyer@fedoraproject.org wrote:
Pretty much what we discussed on IRC yesterday. Anyone have problems with me committing this today?
josh
diff --git a/gnome-shell.spec b/gnome-shell.spec index a085076..94e284d 100644 --- a/gnome-shell.spec +++ b/gnome-shell.spec @@ -102,8 +102,6 @@ Requires: gdm-libs%{?_isa} Requires: clutter%{?_isa} >= %{clutter_version} # needed for settings items in menus Requires: control-center -# needed for captive portal support -Requires: NetworkManager-config-connectivity-fedora
%description GNOME Shell provides core user interface functions for the GNOME 3 desktop, diff --git a/fedora-release.spec b/fedora-release.spec index 333875f..1d7db6b 100644 --- a/fedora-release.spec +++ b/fedora-release.spec @@ -72,6 +72,8 @@ Requires: fedora-release = %{version}-%{release} Conflicts: fedora-release-cloud Conflicts: fedora-release-server Conflicts: fedora-release-standard +# needed for captive portal support +Requires: NetworkManager-config-connectivity-fedora
%description workstation Provides a base package for Fedora Workstation-specific configuration files to
please use git send-email and send me patches from the repo at git://git.fedorahosted.org/git/fedora-release.git/ for both f21 and master branches for fedora-release changes please.
Um... ok. Or I could just commit them... is there a problem with me doing that?
josh
The package is maintained in Fedora hosted git not the package git and it has a specifc set of processes around how updates are done.
Dennis
On Tue, Sep 30, 2014 at 3:42 PM, Dennis Gilmore dennis@ausil.us wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Tue, 30 Sep 2014 14:10:24 -0400 Josh Boyer jwboyer@fedoraproject.org wrote:
On Tue, Sep 30, 2014 at 1:41 PM, Dennis Gilmore dennis@ausil.us wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Tue, 30 Sep 2014 12:49:43 -0400 Josh Boyer jwboyer@fedoraproject.org wrote:
Pretty much what we discussed on IRC yesterday. Anyone have problems with me committing this today?
josh
diff --git a/gnome-shell.spec b/gnome-shell.spec index a085076..94e284d 100644 --- a/gnome-shell.spec +++ b/gnome-shell.spec @@ -102,8 +102,6 @@ Requires: gdm-libs%{?_isa} Requires: clutter%{?_isa} >= %{clutter_version} # needed for settings items in menus Requires: control-center -# needed for captive portal support -Requires: NetworkManager-config-connectivity-fedora
%description GNOME Shell provides core user interface functions for the GNOME 3 desktop, diff --git a/fedora-release.spec b/fedora-release.spec index 333875f..1d7db6b 100644 --- a/fedora-release.spec +++ b/fedora-release.spec @@ -72,6 +72,8 @@ Requires: fedora-release = %{version}-%{release} Conflicts: fedora-release-cloud Conflicts: fedora-release-server Conflicts: fedora-release-standard +# needed for captive portal support +Requires: NetworkManager-config-connectivity-fedora
%description workstation Provides a base package for Fedora Workstation-specific configuration files to
please use git send-email and send me patches from the repo at git://git.fedorahosted.org/git/fedora-release.git/ for both f21 and master branches for fedora-release changes please.
Um... ok. Or I could just commit them... is there a problem with me doing that?
josh
The package is maintained in Fedora hosted git not the package git and it has a specifc set of processes around how updates are done.
Ah, fair enough. I'll send a patch against the upstream git repo then.
josh
On Tue, Sep 30, 2014 at 6:49 PM, Josh Boyer jwboyer@fedoraproject.org wrote:
Pretty much what we discussed on IRC yesterday. Anyone have problems with me committing this today?
josh
diff --git a/gnome-shell.spec b/gnome-shell.spec index a085076..94e284d 100644 --- a/gnome-shell.spec +++ b/gnome-shell.spec @@ -102,8 +102,6 @@ Requires: gdm-libs%{?_isa} Requires: clutter%{?_isa} >= %{clutter_version} # needed for settings items in menus Requires: control-center -# needed for captive portal support -Requires: NetworkManager-config-connectivity-fedora
%description GNOME Shell provides core user interface functions for the GNOME 3 desktop, diff --git a/fedora-release.spec b/fedora-release.spec index 333875f..1d7db6b 100644 --- a/fedora-release.spec +++ b/fedora-release.spec @@ -72,6 +72,8 @@ Requires: fedora-release = %{version}-%{release} Conflicts: fedora-release-cloud Conflicts: fedora-release-server Conflicts: fedora-release-standard +# needed for captive portal support +Requires: NetworkManager-config-connectivity-fedora
%description workstation Provides a base package for Fedora Workstation-specific configuration files to
I don't really like that people that do upgrades get a worse experience because of that pointless change but well ...
On Tue, Sep 30, 2014 at 1:44 PM, drago01 drago01@gmail.com wrote:
On Tue, Sep 30, 2014 at 6:49 PM, Josh Boyer jwboyer@fedoraproject.org wrote:
Pretty much what we discussed on IRC yesterday. Anyone have problems with me committing this today?
josh
diff --git a/gnome-shell.spec b/gnome-shell.spec index a085076..94e284d 100644 --- a/gnome-shell.spec +++ b/gnome-shell.spec @@ -102,8 +102,6 @@ Requires: gdm-libs%{?_isa} Requires: clutter%{?_isa} >= %{clutter_version} # needed for settings items in menus Requires: control-center -# needed for captive portal support -Requires: NetworkManager-config-connectivity-fedora
%description GNOME Shell provides core user interface functions for the GNOME 3 desktop, diff --git a/fedora-release.spec b/fedora-release.spec index 333875f..1d7db6b 100644 --- a/fedora-release.spec +++ b/fedora-release.spec @@ -72,6 +72,8 @@ Requires: fedora-release = %{version}-%{release} Conflicts: fedora-release-cloud Conflicts: fedora-release-server Conflicts: fedora-release-standard +# needed for captive portal support +Requires: NetworkManager-config-connectivity-fedora
%description workstation Provides a base package for Fedora Workstation-specific configuration files to
I don't really like that people that do upgrades get a worse experience because of that pointless change but well ...
There's nothing that says a user doing an upgrade wants to upgrade to Workstation. There's also nothing that is going to magically upgrade them to Workstation anyway. Also, they don't have this in F20 so their experience is not worse, it's the same.
josh
On Tue, Sep 30, 2014 at 8:12 PM, Josh Boyer jwboyer@fedoraproject.org wrote:
On Tue, Sep 30, 2014 at 1:44 PM, drago01 drago01@gmail.com wrote:
On Tue, Sep 30, 2014 at 6:49 PM, Josh Boyer jwboyer@fedoraproject.org wrote:
Pretty much what we discussed on IRC yesterday. Anyone have problems with me committing this today?
josh
diff --git a/gnome-shell.spec b/gnome-shell.spec index a085076..94e284d 100644 --- a/gnome-shell.spec +++ b/gnome-shell.spec @@ -102,8 +102,6 @@ Requires: gdm-libs%{?_isa} Requires: clutter%{?_isa} >= %{clutter_version} # needed for settings items in menus Requires: control-center -# needed for captive portal support -Requires: NetworkManager-config-connectivity-fedora
%description GNOME Shell provides core user interface functions for the GNOME 3 desktop, diff --git a/fedora-release.spec b/fedora-release.spec index 333875f..1d7db6b 100644 --- a/fedora-release.spec +++ b/fedora-release.spec @@ -72,6 +72,8 @@ Requires: fedora-release = %{version}-%{release} Conflicts: fedora-release-cloud Conflicts: fedora-release-server Conflicts: fedora-release-standard +# needed for captive portal support +Requires: NetworkManager-config-connectivity-fedora
%description workstation Provides a base package for Fedora Workstation-specific configuration files to
I don't really like that people that do upgrades get a worse experience because of that pointless change but well ...
There's nothing that says a user doing an upgrade wants to upgrade to Workstation. There's also nothing that is going to magically upgrade them to Workstation anyway.
Which is an different issue and is not really relevant here. The user has been using GNOME upgrades to a new release and should have the experience designed in the new GNOME release.
Also, they don't have this in F20 so their experience is not worse, it's the same.
It's worse than someone that re installs F21 which is my point (also the reason why the dep has been added to gnome-shell). Compare that cost to the gain of the change. The latter is basically non existent. I mean if we would solve some big problem by that that might be an OK trade off .... but we aren't.
Hi
On Tue, Sep 30, 2014 at 2:53 PM, drago01 wrote:
Which is an different issue and is not really relevant here. The user has been using GNOME upgrades to a new release and should have the experience designed in the new GNOME release.
Provide a gnome/fedora workstation group with the experience you want and integrate that as an option with the upgrade tool
Rahul
On Tue, Sep 30, 2014 at 9:31 PM, Rahul Sundaram metherid@gmail.com wrote:
Hi
On Tue, Sep 30, 2014 at 2:53 PM, drago01 wrote:
Which is an different issue and is not really relevant here. The user has been using GNOME upgrades to a new release and should have the experience designed in the new GNOME release.
Provide a gnome/fedora workstation group with the experience you want and integrate that as an option with the upgrade tool
You missed the point. But anyway I won't waste more time on this. Seems like people prefer pointless changes over good user experience. So be it.
On Tue, 2014-09-30 at 14:12 -0400, Josh Boyer wrote:
I don't really like that people that do upgrades get a worse experience because of that pointless change but well ...
There's nothing that says a user doing an upgrade wants to upgrade to Workstation. There's also nothing that is going to magically upgrade them to Workstation anyway. Also, they don't have this in F20 so their experience is not worse, it's the same.
I think fedup needs to to require specification of the product when upgrading from Fedora 20:
fedup Error message listing the products fedup --product=workstation You get Fedora Workstation fedup --product=server You get Fedora Server fedup --product=none You get a collection of pieces from the Fedora repositories
Without that or some equivalent that keeps people from accidentally getting things that look approximately like Fedora Workstation but *are not* Fedora Workstation, I'm definitely opposed to this change.
- Owen
On Wed, 2014-10-01 at 10:25 -0400, Owen Taylor wrote:
On Tue, 2014-09-30 at 14:12 -0400, Josh Boyer wrote:
I don't really like that people that do upgrades get a worse experience because of that pointless change but well ...
There's nothing that says a user doing an upgrade wants to upgrade to Workstation. There's also nothing that is going to magically upgrade them to Workstation anyway. Also, they don't have this in F20 so their experience is not worse, it's the same.
I think fedup needs to to require specification of the product when upgrading from Fedora 20:
fedup Error message listing the products fedup --product=workstation You get Fedora Workstation fedup --product=server You get Fedora Server fedup --product=none You get a collection of pieces from the Fedora repositories
Without that or some equivalent that keeps people from accidentally getting things that look approximately like Fedora Workstation but *are not* Fedora Workstation, I'm definitely opposed to this change.
I've been trying to work with the packaging folks and the fedup maintainer, but right now it's looking infeasible to do a non-productized (F20) upgrade to a Productized F21. People who want Workstation are going to have to do a clean install. People upgrading from F20 will end up with non-productized F21 (equivalent to a Spin).
I need to follow up on the original devel thread about this.
Basically, the fedup maintainers don't want to spend effort on a one-time upgrade feature, particularly with so little time before release.
Hi
On Wed, Oct 1, 2014 at 4:10 PM, Stephen Gallagher wrote:
Basically, the fedup maintainers don't want to spend effort on a one-time upgrade feature, particularly with so little time before release.
Why is it considered a one time upgrade feature? What if I install Fedora Server and decide to re-purpose that system and want to upgrade it to Fedora Workstation?
Rahul
On Wed, Oct 01, 2014 at 04:17:30PM -0400, Rahul Sundaram wrote:
On Wed, Oct 1, 2014 at 4:10 PM, Stephen Gallagher wrote:
Basically, the fedup maintainers don't want to spend effort on a one-time upgrade feature, particularly with so little time before release.
Why is it considered a one time upgrade feature? What if I install Fedora Server and decide to re-purpose that system and want to upgrade it to Fedora Workstation?
That really seems like a great time to reinstall. What benefit would there be in upgrading?
But, if you really, really want to do it, the straightforward answer would be to convert it Workstation and _then_ upgrade. I don't think switching between products at upgrade time is anything we want to support, is it? It seems like an unrelated thing.
Hi
On Wed, Oct 1, 2014 at 7:07 PM, Matthew Miller wrote:
That really seems like a great time to reinstall. What benefit would there
be in upgrading?
I can only speculate but if I say install the KDE spin and want to try out Fedora Workstation, should I reinstall? I would prefer not to.
But, if you really, really want to do it, the straightforward answer would
be to convert it Workstation and _then_ upgrade. I don't think switching between products at upgrade time is anything we want to support, is it? It seems like an unrelated thing.
Perhaps it is but if that isn't going to be supported, it should be documented as part of the upgrade story for users moving from Fedora 20 or earlier. Some of the questions that needs to answered include
*) Can I continue to upgrade Fedora 20 without moving to using one of the products? *) Can I move between products? *) Can I move from non productized installations to one of the products and vice versa? *) How do I differentiate between what is part of the product and what is not and what is the effect on upgrades?
I intend to add notes to the "Upgrading" page in the wiki.
Rahul
On Wed, 2014-10-01 at 19:26 -0400, Rahul Sundaram wrote:
Hi
On Wed, Oct 1, 2014 at 7:07 PM, Matthew Miller wrote:
That really seems like a great time to reinstall. What benefit would
there be in upgrading?
I can only speculate but if I say install the KDE spin and want to try out Fedora Workstation, should I reinstall? I would prefer not to.
That's *definitely* not an upgrade use-case. That's better solved by just running 'yum swap fedora-release-standard fedora-release-workstation && yum install "@^fedora-workstation-environment"'
But, if you really, really want to do it, the straightforward answer would be to convert it Workstation and _then_ upgrade. I don't think switching between products at upgrade time is anything we want to support, is it? It seems like an unrelated thing.Perhaps it is but if that isn't going to be supported, it should be documented as part of the upgrade story for users moving from Fedora 20 or earlier. Some of the questions that needs to answered include
Please see the thread I started on devel@ which addresses these questions.
*) Can I continue to upgrade Fedora 20 without moving to using one of the products?
At the moment, that's the only upgrade path we're likely to be able to manage.
*) Can I move between products?
Yes, but it will require manual steps. Installing the *packages* from another environment is fairly easy.
*) Can I move from non productized installations to one of the products and vice versa?
Same answer as the previous question.
*) How do I differentiate between what is part of the product and what is not and what is the effect on upgrades?
I'm not sure what you mean here. From the upgrade tools' perspectives, a package is a package.
I intend to add notes to the "Upgrading" page in the wiki.
Rahul
-- desktop mailing list desktop@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/desktop
Hi
On Wed, Oct 1, 2014 at 7:48 PM, Stephen Gallagher wrote:
*) How do I differentiate between what is part of the product and what is not and what is the effect on upgrades?
I'm not sure what you mean here. From the upgrade tools' perspectives, a package is a package.
Sure but if we say these are the sets of the packages that we are going to focus on for say Fedora Workstation or Fedora Server and assuming not all of them are installed by default and I want to stay within the borders of what that particular product considers their focus, I would want to quickly list packages that are not part of the product before upgrading. This could matter even more when say Fedora Server has a different lifecycle from the rest of the packages. Does that make sense?
Rahul
On Wed, 2014-10-01 at 20:00 -0400, Rahul Sundaram wrote:
Hi
On Wed, Oct 1, 2014 at 7:48 PM, Stephen Gallagher wrote:
> *) How do I differentiate between what is part of the > product and what is not and what is the effect on upgrades? > I'm not sure what you mean here. From the upgrade tools' perspectives, a package is a package.Sure but if we say these are the sets of the packages that we are going to focus on for say Fedora Workstation or Fedora Server and assuming not all of them are installed by default and I want to stay within the borders of what that particular product considers their focus, I would want to quickly list packages that are not part of the product before upgrading. This could matter even more when say Fedora Server has a different lifecycle from the rest of the packages. Does that make sense?
Unfortunately, that's a much harder task than it sounds (and also not terribly useful). Just because we have a set of software that defines the PLATFORM does not somehow make the other packages that you choose to install less interesting. (Quite the opposite, really. The platform is only interesting insofar as it allows you to run things atop it.)
Hi
On Wed, Oct 1, 2014 at 8:39 PM, Stephen Gallagher wrote:
Unfortunately, that's a much harder task than it sounds (and also not terribly useful). Just because we have a set of software that defines the PLATFORM does not somehow make the other packages that you choose to install less interesting. (Quite the opposite, really. The platform is only interesting insofar as it allows you to run things atop it.)
Agreed on the question of platform but I do think it is quite useful to find out what lies outside the defined platform and I often do similar things for dealing with upgrades. yum list extras to find out which packages are not associated with any repositories tells me what I need to pay special attention to before doing the upgrade for example.
Fedora Workstation uses GNOME Software to gate packages to some extend (by filtering out some packages that don't meet a specific criteria) but it is unclear how Fedora Server will handle that. I may not agree with all the criteria but it is atleast a workable mechanism to do what is needed here.
From a professional perspective, I have recently been asked to take over
administration of legacy systems and finding out what has been setup in a non standardized way is a key part of figuring out how to replicate it. If some packages can have a different lifecycle from other packages, this is critically important and hooks within the upgrade tool to do some of the checks before the upgrade process is initiated would be highly useful.
Rahul
On Wed, Oct 01, 2014 at 07:26:54PM -0400, Rahul Sundaram wrote:
That really seems like a great time to reinstall. What benefit would there be in upgrading?
I can only speculate but if I say install the KDE spin and want to try out Fedora Workstation, should I reinstall? I would prefer not to.
I understand why you might want to try things without reinstalling. However, I'm not sure why that would be linked to _upgrading_.
Perhaps it is but if that isn't going to be supported, it should be documented as part of the upgrade story for users moving from Fedora 20 or earlier. Some of the questions that needs to answered include *) Can I continue to upgrade Fedora 20 without moving to using one of the products?
This should be "yes", but it's also an area where I don't think we're going to put much focus unless a team wants to step forward to maintain it. (I'm all for it in theory.)
*) Can I move between products?
There is a feature for an official path from Cloud -> Server. (Needs work from, um, me. But in theory.) I think all other paths will be possible with manual work but I don't think will be supported.
*) Can I move from non productized installations to one of the products and vice versa?
Productized -> non is fairly easy; the reverse may be in the same category as yum-based online updates: not the recommended way, but... a thing that usually works and is great when it does.
*) How do I differentiate between what is part of the product and what is not and what is the effect on upgrades?
fedora-release-product, and the comps group.
I intend to add notes to the "Upgrading" page in the wiki.
Thanks -- that's helpful. With that in mind, note that none of the above is official. It's what I am thinking at 10pm after a long day. :)
Hi
On Wed, Oct 1, 2014 at 9:47 PM, Matthew Miller wrote:
I understand why you might want to try things without reinstalling. However, I'm not sure why that would be linked to _upgrading_.
It is not strictly related but if we are providing a specialized tool to deal with this type of changes, we don't have anything else other than fedup at this point.
Thanks -- that's helpful. With that in mind, note that none of the above
is
official. It's what I am thinking at 10pm after a long day. :)
That's fine. I understand authoritative answers may not exist at this point. I will try to distill down any discussions and we will see how that goes
Rahul
Hi
On Wed, Oct 1, 2014 at 9:47 PM, Matthew Miller wrote:
On Wed, Oct 01, 2014 at 07:26:54PM -0400, Rahul Sundaram wrote:
*) Can I continue to upgrade Fedora 20 without moving to using one of
the
products?
This should be "yes", but it's also an area where I don't think we're going to put much focus unless a team wants to step forward to maintain it. (I'm all for it in theory.)
While writing the notes, it struck me that fedora-release-standard is a particularly bad name for something we aren't going to be focusing on. Can this be renamed?
Rahul
On Thu, Oct 02, 2014 at 07:17:46PM -0400, Rahul Sundaram wrote:
While writing the notes, it struck me that fedora-release-standard is a particularly bad name for something we aren't going to be focusing on. Can this be renamed?
I agree but I think we weren't in the majority. I thought "fedora-release-vanilla" was nice. :)
On Thu, 2014-10-02 at 19:21 -0400, Matthew Miller wrote:
On Thu, Oct 02, 2014 at 07:17:46PM -0400, Rahul Sundaram wrote:
While writing the notes, it struck me that fedora-release-standard is a particularly bad name for something we aren't going to be focusing on. Can this be renamed?
I agree but I think we weren't in the majority. I thought "fedora-release-vanilla" was nice. :)
IIRC, I originally proposed fedora-release-generic and fedora-release-legacy, but this gave a too-negative connotation to the Spins maintainers, so we settled on 'standard'. I don't care much for it either, but it's something people generally don't see unless they REALLY look for it (or are a packager).
Hi
On Thu, Oct 2, 2014 at 7:26 PM, Stephen Gallagher wrote:
IIRC, I originally proposed fedora-release-generic and fedora-release-legacy, but this gave a too-negative connotation to the Spins maintainers, so we settled on 'standard'. I don't care much for it either, but it's something people generally don't see unless they REALLY look for it (or are a packager).
This is true for new users (and hopefully there will be many of them) but existing release users including spins etc will be seeing this as part of the upgrade. Standard really suggests that products are non-standard which is exactly the wrong impression to provide. generic or vanilla seem much better.
Meanwhile I have added some quick notes to
https://fedoraproject.org/wiki/Upgrading
I will flesh it out as we get closer to the release. Help welcome.
Rahul
On Thu, 2014-10-02 at 19:33 -0400, Rahul Sundaram wrote:
Hi
On Thu, Oct 2, 2014 at 7:26 PM, Stephen Gallagher wrote: IIRC, I originally proposed fedora-release-generic and fedora-release-legacy, but this gave a too-negative connotation to the Spins maintainers, so we settled on 'standard'. I don't care much for it either, but it's something people generally don't see unless they REALLY look for it (or are a packager).
This is true for new users (and hopefully there will be many of them) but existing release users including spins etc will be seeing this as part of the upgrade. Standard really suggests that products are non-standard which is exactly the wrong impression to provide. generic or vanilla seem much better.
Well "seeing this as part of the upgrade" is a bit strong. I don't know about you, but I don't actually examine every single package that fedup adds to my system. Packagers will know it's there, but the average (or even most expert) users will never really notice it unless we draw their attention. The exception of course being the docs we will inevitably write to convert from non-productized to one of the Products.
Anyway, changing it at this point would require an annoying amount of Obsoletes: work that is probably not worth the effort (but if Dennis Gilmore thinks it's worth it, I certainly won't stop him).
On Wed, 2014-10-01 at 16:10 -0400, Stephen Gallagher wrote:
On Wed, 2014-10-01 at 10:25 -0400, Owen Taylor wrote:
On Tue, 2014-09-30 at 14:12 -0400, Josh Boyer wrote:
I don't really like that people that do upgrades get a worse experience because of that pointless change but well ...
There's nothing that says a user doing an upgrade wants to upgrade to Workstation. There's also nothing that is going to magically upgrade them to Workstation anyway. Also, they don't have this in F20 so their experience is not worse, it's the same.
I think fedup needs to to require specification of the product when upgrading from Fedora 20: [...]
I've been trying to work with the packaging folks and the fedup maintainer, but right now it's looking infeasible to do a non-productized (F20) upgrade to a Productized F21. People who want Workstation are going to have to do a clean install. People upgrading from F20 will end up with non-productized F21 (equivalent to a Spin).
In the Fedora Workstation PRD we have:
Robust Upgrades
Upgrading the system multiple times through the upgrade process should give a result that is the same as an original install of Fedora Workstation. Upgrade should be a safe and process that never leaves the system needing manual intervention.
This refers, of course, to upgrades between versions of Fedora Workstation, but I think we're sending a strong message in the wrong direction if we make it require a complex manual procedure to upgrade from F20 to F21 Workstation.
If the initial version of Fedora Workstation was a huge technical change involving different packaging systems, different filesystems, and so forth, I could see that we might want to require a fresh install a single time with a promise that things would be better in the future - but this really isn't the case.
I need to follow up on the original devel thread about this.
Basically, the fedup maintainers don't want to spend effort on a one-time upgrade feature, particularly with so little time before release.
If https://github.com/wgwoods/fedup is the right upstream repository for fedup, it doesn't look like it has gotten much work this cycle - presumably because priorities are on different projects. How can the Fedora Workstation WG lend a hand?
- Owen
On Thu, Oct 02, 2014 at 08:26:56PM -0400, Owen Taylor wrote:
If https://github.com/wgwoods/fedup is the right upstream repository for fedup, it doesn't look like it has gotten much work this cycle - presumably because priorities are on different projects. How can the Fedora Workstation WG lend a hand?
Probably worth talking to Will?
On Thu, 2014-10-02 at 20:26 -0400, Owen Taylor wrote:
On Wed, 2014-10-01 at 16:10 -0400, Stephen Gallagher wrote:
On Wed, 2014-10-01 at 10:25 -0400, Owen Taylor wrote:
On Tue, 2014-09-30 at 14:12 -0400, Josh Boyer wrote:
I don't really like that people that do upgrades get a worse experience because of that pointless change but well ...
There's nothing that says a user doing an upgrade wants to upgrade to Workstation. There's also nothing that is going to magically upgrade them to Workstation anyway. Also, they don't have this in F20 so their experience is not worse, it's the same.
I think fedup needs to to require specification of the product when upgrading from Fedora 20: [...]
I've been trying to work with the packaging folks and the fedup maintainer, but right now it's looking infeasible to do a non-productized (F20) upgrade to a Productized F21. People who want Workstation are going to have to do a clean install. People upgrading from F20 will end up with non-productized F21 (equivalent to a Spin).
In the Fedora Workstation PRD we have:
Robust Upgrades
Upgrading the system multiple times through the upgrade process should give a result that is the same as an original install of Fedora Workstation. Upgrade should be a safe and process that never leaves the system needing manual intervention.
This refers, of course, to upgrades between versions of Fedora Workstation, but I think we're sending a strong message in the wrong direction if we make it require a complex manual procedure to upgrade from F20 to F21 Workstation.
Well, the procedure isn't necessarily *complex*, but it *is* necessarily manual. Please see my email on devel@, I talked about the actual technical issues that are getting in the way here (and the fact that we're dangerously close to Beta for trying to land entirely new code in fedup...)
If the initial version of Fedora Workstation was a huge technical change involving different packaging systems, different filesystems, and so forth, I could see that we might want to require a fresh install a single time with a promise that things would be better in the future - but this really isn't the case.
Well, to a lesser extent, this *is* a new packaging system; we're asking for the capability to install a different set of packages based on which Product you *might* want to upgrade to.
I need to follow up on the original devel thread about this.
Basically, the fedup maintainers don't want to spend effort on a one-time upgrade feature, particularly with so little time before release.
If https://github.com/wgwoods/fedup is the right upstream repository for fedup, it doesn't look like it has gotten much work this cycle - presumably because priorities are on different projects. How can the Fedora Workstation WG lend a hand?
We can have another conversation with Will. I'm attaching a log of the last exchange so that we don't have to repeat all of it again.
On Fri, 2014-10-03 at 09:00 -0400, Stephen Gallagher wrote:
On Thu, 2014-10-02 at 20:26 -0400, Owen Taylor wrote:
On Wed, 2014-10-01 at 16:10 -0400, Stephen Gallagher wrote:
On Wed, 2014-10-01 at 10:25 -0400, Owen Taylor wrote:
On Tue, 2014-09-30 at 14:12 -0400, Josh Boyer wrote:
I don't really like that people that do upgrades get a worse experience because of that pointless change but well ...
There's nothing that says a user doing an upgrade wants to upgrade to Workstation. There's also nothing that is going to magically upgrade them to Workstation anyway. Also, they don't have this in F20 so their experience is not worse, it's the same.
I think fedup needs to to require specification of the product when upgrading from Fedora 20: [...]
I've been trying to work with the packaging folks and the fedup maintainer, but right now it's looking infeasible to do a non-productized (F20) upgrade to a Productized F21. People who want Workstation are going to have to do a clean install. People upgrading from F20 will end up with non-productized F21 (equivalent to a Spin).
In the Fedora Workstation PRD we have:
Robust Upgrades
Upgrading the system multiple times through the upgrade process should give a result that is the same as an original install of Fedora Workstation. Upgrade should be a safe and process that never leaves the system needing manual intervention.
This refers, of course, to upgrades between versions of Fedora Workstation, but I think we're sending a strong message in the wrong direction if we make it require a complex manual procedure to upgrade from F20 to F21 Workstation.
Well, the procedure isn't necessarily *complex*, but it *is* necessarily manual. Please see my email on devel@, I talked about the actual technical issues that are getting in the way here (and the fact that we're dangerously close to Beta for trying to land entirely new code in fedup...)
There's three separate things here:
* We need to make it almost impossible to *accidentally* upgrade to non-productized F21 and think you are getting the Workstation experience.
* We need to provide a feasible way to upgrade from F20 Fedora 21 Workstation.
* We want to provide a slick, competitive, professional upgrade experience.
If we are willing to give up the last, we can satisfy the first two by a warning message in fedup and a wiki page. What we shouldn't do is concentrate on the last one at the expense of the first two.
If the initial version of Fedora Workstation wa
a huge technical change
involving different packaging systems, different filesystems, and so forth, I could see that we might want to require a fresh install a single time with a promise that things would be better in the future - but this really isn't the case>
Well, to a lesser extent, this *is* a new packaging system; we're asking for the capability to install a different set of packages based on which Product you *might* want to upgrade to.
Reinstallation isn't something we can take lightly. A user that is told that they need to reinstall to go to the next version of Fedora make well take that opportunity to try out some other Linux distribution. Not to mention that it's really inconvenient for the user and quite likely hazardous to their data!
We should only ever be thinking of fresh installs if there no other way to get to the end goal.
Beyond that, if we are recommending reinstallation at some point, it's our responsibility to have a carefully constructed reinstallation experience that walks the user through backing up their data, determines if there is other data on the system that might be lost (e.g., databases in /var/lib), and probably tries to migrate some aspects of account configuration to the new system.
As I recall, there is am option to replace existing Fedora installation' option in the installer but to my thinking you need a lot more than that. It's a pretty big project.
- Owen
On Fri, 2014-10-03 at 14:21 -0400, Owen Taylor wrote:
On Fri, 2014-10-03 at 09:00 -0400, Stephen Gallagher wrote:
On Thu, 2014-10-02 at 20:26 -0400, Owen Taylor wrote:
On Wed, 2014-10-01 at 16:10 -0400, Stephen Gallagher wrote:
On Wed, 2014-10-01 at 10:25 -0400, Owen Taylor wrote:
On Tue, 2014-09-30 at 14:12 -0400, Josh Boyer wrote:
> I don't really like that people that do upgrades get a worse > experience because of that pointless change but well ...
There's nothing that says a user doing an upgrade wants to upgrade to Workstation. There's also nothing that is going to magically upgrade them to Workstation anyway. Also, they don't have this in F20 so their experience is not worse, it's the same.
I think fedup needs to to require specification of the product when upgrading from Fedora 20: [...]
I've been trying to work with the packaging folks and the fedup maintainer, but right now it's looking infeasible to do a non-productized (F20) upgrade to a Productized F21. People who want Workstation are going to have to do a clean install. People upgrading from F20 will end up with non-productized F21 (equivalent to a Spin).
In the Fedora Workstation PRD we have:
Robust Upgrades
Upgrading the system multiple times through the upgrade process should give a result that is the same as an original install of Fedora Workstation. Upgrade should be a safe and process that never leaves the system needing manual intervention.
This refers, of course, to upgrades between versions of Fedora Workstation, but I think we're sending a strong message in the wrong direction if we make it require a complex manual procedure to upgrade from F20 to F21 Workstation.
Well, the procedure isn't necessarily *complex*, but it *is* necessarily manual. Please see my email on devel@, I talked about the actual technical issues that are getting in the way here (and the fact that we're dangerously close to Beta for trying to land entirely new code in fedup...)
There's three separate things here:
- We need to make it almost impossible to *accidentally* upgrade to non-productized F21 and think you are getting the Workstation experience.
I think this is the wrong way of thinking about this. As noted elsewhere in this or the other thread, we *cannot* make the assumption that someone upgrading from F20 actually *wants* it to be Fedora Workstation, even if they happen to have the GNOME desktop installed.
There are plenty of people who are using a system installed from one of the spins as well as people who are using Fedora as a server (possibly headless) and having the upgrade process result in Workstation except when *explicitly* chosen is not acceptable.
- We need to provide a feasible way to upgrade from F20 Fedora 21 Workstation.
I would certainly be in favor of having this. The definition of "feasible" is very complicated, though. This can be solved, but it's debatable if it can be solved sensibly in the remaining time. (See the explanations in the other thread).
Also, if the Fedora Workstation group feels that this needs to be considered a blocker (for Beta, since that's our only chance to have it tested before Final), then we need to have this agreed upon immediately and added to the Beta Blocker criteria.
- We want to provide a slick, competitive, professional upgrade experience.
If we are willing to give up the last, we can satisfy the first two by a warning message in fedup and a wiki page. What we shouldn't do is concentrate on the last one at the expense of the first two.
I'm not really sure I follow here. The manual steps are not trivial, so I'm afraid that a warning message and a wiki page may be more unnerving to users than we would like.
If the initial version of Fedora Workstation wa
a huge technical change
involving different packaging systems, different filesystems, and so forth, I could see that we might want to require a fresh install a single time with a promise that things would be better in the future - but this really isn't the case>
Well, to a lesser extent, this *is* a new packaging system; we're asking for the capability to install a different set of packages based on which Product you *might* want to upgrade to.
Reinstallation isn't something we can take lightly. A user that is told that they need to reinstall to go to the next version of Fedora make well take that opportunity to try out some other Linux distribution. Not to mention that it's really inconvenient for the user and quite likely hazardous to their data!
Fair points. As I've said, I *want* to be able to upgrade to Workstation sensibly, but we have technical hurdles to overcome to accomplish that and very limited time.
We should only ever be thinking of fresh installs if there no other way to get to the end goal.
Beyond that, if we are recommending reinstallation at some point, it's our responsibility to have a carefully constructed reinstallation experience that walks the user through backing up their data, determines if there is other data on the system that might be lost (e.g., databases in /var/lib), and probably tries to migrate some aspects of account configuration to the new system.
Let's put this on the back-burner. I'm pretty sure we want to do this someday no matter what, but this is quickly going to rat-hole.
As I recall, there is am option to replace existing Fedora installation' option in the installer but to my thinking you need a lot more than that. It's a pretty big project.
- Owen
On Fri, Oct 3, 2014 at 8:42 PM, Stephen Gallagher sgallagh@redhat.com wrote:
On Fri, 2014-10-03 at 14:21 -0400, Owen Taylor wrote:
On Fri, 2014-10-03 at 09:00 -0400, Stephen Gallagher wrote:
On Thu, 2014-10-02 at 20:26 -0400, Owen Taylor wrote:
On Wed, 2014-10-01 at 16:10 -0400, Stephen Gallagher wrote:
On Wed, 2014-10-01 at 10:25 -0400, Owen Taylor wrote:
On Tue, 2014-09-30 at 14:12 -0400, Josh Boyer wrote: > > I don't really like that people that do upgrades get a worse > > experience because of that pointless change but well ... > > There's nothing that says a user doing an upgrade wants to upgrade to > Workstation. There's also nothing that is going to magically upgrade > them to Workstation anyway. Also, they don't have this in F20 so > their experience is not worse, it's the same.
I think fedup needs to to require specification of the product when upgrading from Fedora 20: [...]
I've been trying to work with the packaging folks and the fedup maintainer, but right now it's looking infeasible to do a non-productized (F20) upgrade to a Productized F21. People who want Workstation are going to have to do a clean install. People upgrading from F20 will end up with non-productized F21 (equivalent to a Spin).
In the Fedora Workstation PRD we have:
Robust Upgrades
Upgrading the system multiple times through the upgrade process should give a result that is the same as an original install of Fedora Workstation. Upgrade should be a safe and process that never leaves the system needing manual intervention.
This refers, of course, to upgrades between versions of Fedora Workstation, but I think we're sending a strong message in the wrong direction if we make it require a complex manual procedure to upgrade from F20 to F21 Workstation.
Well, the procedure isn't necessarily *complex*, but it *is* necessarily manual. Please see my email on devel@, I talked about the actual technical issues that are getting in the way here (and the fact that we're dangerously close to Beta for trying to land entirely new code in fedup...)
There's three separate things here:
- We need to make it almost impossible to *accidentally* upgrade to non-productized F21 and think you are getting the Workstation experience.
I think this is the wrong way of thinking about this. As noted elsewhere in this or the other thread, we *cannot* make the assumption that someone upgrading from F20 actually *wants* it to be Fedora Workstation, even if they happen to have the GNOME desktop installed.
There are plenty of people who are using a system installed from one of the spins as well as people who are using Fedora as a server (possibly headless) and having the upgrade process result in Workstation except when *explicitly* chosen is not acceptable.
- We need to provide a feasible way to upgrade from F20 Fedora 21 Workstation.
I would certainly be in favor of having this. The definition of "feasible" is very complicated, though. This can be solved, but it's debatable if it can be solved sensibly in the remaining time. (See the explanations in the other thread).
Why from the chatlog you attached elsewhere one would conclude that the "yum install fedora-relase-foo && fedup" would work. Or what did I miss?
On Fri, 2014-10-03 at 20:45 +0200, drago01 wrote:
On Fri, Oct 3, 2014 at 8:42 PM, Stephen Gallagher sgallagh@redhat.com wrote:
On Fri, 2014-10-03 at 14:21 -0400, Owen Taylor wrote:
On Fri, 2014-10-03 at 09:00 -0400, Stephen Gallagher wrote:
On Thu, 2014-10-02 at 20:26 -0400, Owen Taylor wrote:
On Wed, 2014-10-01 at 16:10 -0400, Stephen Gallagher wrote:
On Wed, 2014-10-01 at 10:25 -0400, Owen Taylor wrote: > On Tue, 2014-09-30 at 14:12 -0400, Josh Boyer wrote: > > > I don't really like that people that do upgrades get a worse > > > experience because of that pointless change but well ... > > > > There's nothing that says a user doing an upgrade wants to upgrade to > > Workstation. There's also nothing that is going to magically upgrade > > them to Workstation anyway. Also, they don't have this in F20 so > > their experience is not worse, it's the same. > > I think fedup needs to to require specification of the product when > upgrading from Fedora 20: > [...]
I've been trying to work with the packaging folks and the fedup maintainer, but right now it's looking infeasible to do a non-productized (F20) upgrade to a Productized F21. People who want Workstation are going to have to do a clean install. People upgrading from F20 will end up with non-productized F21 (equivalent to a Spin).
In the Fedora Workstation PRD we have:
Robust Upgrades
Upgrading the system multiple times through the upgrade process should give a result that is the same as an original install of Fedora Workstation. Upgrade should be a safe and process that never leaves the system needing manual intervention.
This refers, of course, to upgrades between versions of Fedora Workstation, but I think we're sending a strong message in the wrong direction if we make it require a complex manual procedure to upgrade from F20 to F21 Workstation.
Well, the procedure isn't necessarily *complex*, but it *is* necessarily manual. Please see my email on devel@, I talked about the actual technical issues that are getting in the way here (and the fact that we're dangerously close to Beta for trying to land entirely new code in fedup...)
There's three separate things here:
- We need to make it almost impossible to *accidentally* upgrade to non-productized F21 and think you are getting the Workstation experience.
I think this is the wrong way of thinking about this. As noted elsewhere in this or the other thread, we *cannot* make the assumption that someone upgrading from F20 actually *wants* it to be Fedora Workstation, even if they happen to have the GNOME desktop installed.
There are plenty of people who are using a system installed from one of the spins as well as people who are using Fedora as a server (possibly headless) and having the upgrade process result in Workstation except when *explicitly* chosen is not acceptable.
- We need to provide a feasible way to upgrade from F20 Fedora 21 Workstation.
I would certainly be in favor of having this. The definition of "feasible" is very complicated, though. This can be solved, but it's debatable if it can be solved sensibly in the remaining time. (See the explanations in the other thread).
Why from the chatlog you attached elsewhere one would conclude that the "yum install fedora-relase-foo && fedup" would work. Or what did I miss?
You missed the part where that approach takes away the no-manual-steps part of it. If we go that path, then you MUST explicitly do 'yum install fedora-release-[standard|workstation|cloud|server]' before you can run fedup.
If people feel that this is an acceptable approach, we can investigate it, but the general sense I was getting is that "fedup --network 21" should work on its own with no other interaction. If we can relax that requirement, this is a viable approach.
On Fri, Oct 3, 2014 at 9:01 PM, Stephen Gallagher sgallagh@redhat.com wrote:
On Fri, 2014-10-03 at 20:45 +0200, drago01 wrote:
On Fri, Oct 3, 2014 at 8:42 PM, Stephen Gallagher sgallagh@redhat.com wrote:
On Fri, 2014-10-03 at 14:21 -0400, Owen Taylor wrote:
On Fri, 2014-10-03 at 09:00 -0400, Stephen Gallagher wrote:
On Thu, 2014-10-02 at 20:26 -0400, Owen Taylor wrote:
On Wed, 2014-10-01 at 16:10 -0400, Stephen Gallagher wrote: > On Wed, 2014-10-01 at 10:25 -0400, Owen Taylor wrote: > > On Tue, 2014-09-30 at 14:12 -0400, Josh Boyer wrote: > > > > I don't really like that people that do upgrades get a worse > > > > experience because of that pointless change but well ... > > > > > > There's nothing that says a user doing an upgrade wants to upgrade to > > > Workstation. There's also nothing that is going to magically upgrade > > > them to Workstation anyway. Also, they don't have this in F20 so > > > their experience is not worse, it's the same. > > > > I think fedup needs to to require specification of the product when > > upgrading from Fedora 20: > > [...] > > I've been trying to work with the packaging folks and the fedup > maintainer, but right now it's looking infeasible to do a > non-productized (F20) upgrade to a Productized F21. People who want > Workstation are going to have to do a clean install. People upgrading > from F20 will end up with non-productized F21 (equivalent > to a Spin).
In the Fedora Workstation PRD we have:
Robust Upgrades
Upgrading the system multiple times through the upgrade process should give a result that is the same as an original install of Fedora Workstation. Upgrade should be a safe and process that never leaves the system needing manual intervention.
This refers, of course, to upgrades between versions of Fedora Workstation, but I think we're sending a strong message in the wrong direction if we make it require a complex manual procedure to upgrade from F20 to F21 Workstation.
Well, the procedure isn't necessarily *complex*, but it *is* necessarily manual. Please see my email on devel@, I talked about the actual technical issues that are getting in the way here (and the fact that we're dangerously close to Beta for trying to land entirely new code in fedup...)
There's three separate things here:
- We need to make it almost impossible to *accidentally* upgrade to non-productized F21 and think you are getting the Workstation experience.
I think this is the wrong way of thinking about this. As noted elsewhere in this or the other thread, we *cannot* make the assumption that someone upgrading from F20 actually *wants* it to be Fedora Workstation, even if they happen to have the GNOME desktop installed.
There are plenty of people who are using a system installed from one of the spins as well as people who are using Fedora as a server (possibly headless) and having the upgrade process result in Workstation except when *explicitly* chosen is not acceptable.
- We need to provide a feasible way to upgrade from F20 Fedora 21 Workstation.
I would certainly be in favor of having this. The definition of "feasible" is very complicated, though. This can be solved, but it's debatable if it can be solved sensibly in the remaining time. (See the explanations in the other thread).
Why from the chatlog you attached elsewhere one would conclude that the "yum install fedora-relase-foo && fedup" would work. Or what did I miss?
You missed the part where that approach takes away the no-manual-steps part of it. If we go that path, then you MUST explicitly do 'yum install fedora-release-[standard|workstation|cloud|server]' before you can run fedup.
If people feel that this is an acceptable approach, we can investigate it, but the general sense I was getting is that "fedup --network 21" should work on its own with no other interaction.
Well "fedup --network 21" could simply check if any of those packages is present and if not print a message. Shouldn't this be that big of a change.
On Fri, 2014-10-03 at 21:18 +0200, drago01 wrote:
On Fri, Oct 3, 2014 at 9:01 PM, Stephen Gallagher sgallagh@redhat.com wrote:
On Fri, 2014-10-03 at 20:45 +0200, drago01 wrote:
On Fri, Oct 3, 2014 at 8:42 PM, Stephen Gallagher sgallagh@redhat.com wrote:
On Fri, 2014-10-03 at 14:21 -0400, Owen Taylor wrote:
On Fri, 2014-10-03 at 09:00 -0400, Stephen Gallagher wrote:
On Thu, 2014-10-02 at 20:26 -0400, Owen Taylor wrote: > On Wed, 2014-10-01 at 16:10 -0400, Stephen Gallagher wrote: > > On Wed, 2014-10-01 at 10:25 -0400, Owen Taylor wrote: > > > On Tue, 2014-09-30 at 14:12 -0400, Josh Boyer wrote: > > > > > I don't really like that people that do upgrades get a worse > > > > > experience because of that pointless change but well ... > > > > > > > > There's nothing that says a user doing an upgrade wants to upgrade to > > > > Workstation. There's also nothing that is going to magically upgrade > > > > them to Workstation anyway. Also, they don't have this in F20 so > > > > their experience is not worse, it's the same. > > > > > > I think fedup needs to to require specification of the product when > > > upgrading from Fedora 20: > > > [...] > > > > I've been trying to work with the packaging folks and the fedup > > maintainer, but right now it's looking infeasible to do a > > non-productized (F20) upgrade to a Productized F21. People who want > > Workstation are going to have to do a clean install. People upgrading > > from F20 will end up with non-productized F21 (equivalent > > to a Spin). > > In the Fedora Workstation PRD we have: > > Robust Upgrades > > Upgrading the system multiple times through the upgrade process should > give a result that is the same as an original install of Fedora > Workstation. Upgrade should be a safe and process that never leaves the > system needing manual intervention. > > This refers, of course, to upgrades between versions of Fedora > Workstation, but I think we're sending a strong message in the wrong > direction if we make it require a complex manual procedure to upgrade > from F20 to F21 Workstation. >
Well, the procedure isn't necessarily *complex*, but it *is* necessarily manual. Please see my email on devel@, I talked about the actual technical issues that are getting in the way here (and the fact that we're dangerously close to Beta for trying to land entirely new code in fedup...)
There's three separate things here:
- We need to make it almost impossible to *accidentally* upgrade to non-productized F21 and think you are getting the Workstation experience.
I think this is the wrong way of thinking about this. As noted elsewhere in this or the other thread, we *cannot* make the assumption that someone upgrading from F20 actually *wants* it to be Fedora Workstation, even if they happen to have the GNOME desktop installed.
There are plenty of people who are using a system installed from one of the spins as well as people who are using Fedora as a server (possibly headless) and having the upgrade process result in Workstation except when *explicitly* chosen is not acceptable.
- We need to provide a feasible way to upgrade from F20 Fedora 21 Workstation.
I would certainly be in favor of having this. The definition of "feasible" is very complicated, though. This can be solved, but it's debatable if it can be solved sensibly in the remaining time. (See the explanations in the other thread).
Why from the chatlog you attached elsewhere one would conclude that the "yum install fedora-relase-foo && fedup" would work. Or what did I miss?
You missed the part where that approach takes away the no-manual-steps part of it. If we go that path, then you MUST explicitly do 'yum install fedora-release-[standard|workstation|cloud|server]' before you can run fedup.
If people feel that this is an acceptable approach, we can investigate it, but the general sense I was getting is that "fedup --network 21" should work on its own with no other interaction.
Well "fedup --network 21" could simply check if any of those packages is present and if not print a message. Shouldn't this be that big of a change.
Just a bit of an update; the new upgrade plan should be able to resolve this issue without the patch (and also in a way that is likely acceptable to all groups).
We can remove the explicit Requires: NM-captive-portal-fedora from both gnome-shell and fedora-release workstation, because the new 'fedup --network 21 --product=workstation' command will automatically install it as long as it's part of the @^workstation-product-environment group in comps (which a quick inspection shows is not currently the case but is a two-line change that I will submit right now).
Of course, this approach has the same issue as this patch does, which is that it will only ensure that this new package is added to the Workstation upgrades and not to standard upgrades...
Another option would be to take advantage of the new 'Recommends:' dependencies in RPM, but there are two issues with this: 1) I don't know if yum/fedup supports this yet 2) We'd need to ask FPC/FESCo for a special exemption to allow this, since weak dependencies are currently not permitted in Fedora.
If we get this, then we can simply have 'Recommends: NM-captive-portal-fedora' as a dependency of gnome-shell and then it will be installed on all upgrades using gnome-shell, with the option to later remove it if someone has a real desire to do so.
I'll ask the yum and fedup folks whether this is feasible.
On Mon, Oct 6, 2014 at 8:21 AM, Stephen Gallagher sgallagh@redhat.com wrote:
Just a bit of an update; the new upgrade plan should be able to resolve this issue without the patch (and also in a way that is likely acceptable to all groups).
We can remove the explicit Requires: NM-captive-portal-fedora from both gnome-shell and fedora-release workstation, because the new 'fedup --network 21 --product=workstation' command will automatically install it as long as it's part of the @^workstation-product-environment group in comps (which a quick inspection shows is not currently the case but is a two-line change that I will submit right now).
I don't see a need to remove it from fedora-release-workstation now that it is already in and built.
Also, unless I'm misunderstanding something, the environment group doesn't handle cases where someone installs Workstation, the removes pieces of what we consider "core" functionality. At that point they are no longer running Workstation. (I'm not sure we have a good handle on that overall anyway, but removing the current Requires is fairly pointless.)
Of course, this approach has the same issue as this patch does, which is that it will only ensure that this new package is added to the Workstation upgrades and not to standard upgrades...
I still don't think that is bad, given that is the entire reason for the patch in the first place.
josh
On Mon, 2014-10-06 at 08:30 -0400, Josh Boyer wrote:
On Mon, Oct 6, 2014 at 8:21 AM, Stephen Gallagher sgallagh@redhat.com wrote:
Just a bit of an update; the new upgrade plan should be able to resolve this issue without the patch (and also in a way that is likely acceptable to all groups).
We can remove the explicit Requires: NM-captive-portal-fedora from both gnome-shell and fedora-release workstation, because the new 'fedup --network 21 --product=workstation' command will automatically install it as long as it's part of the @^workstation-product-environment group in comps (which a quick inspection shows is not currently the case but is a two-line change that I will submit right now).
I don't see a need to remove it from fedora-release-workstation now that it is already in and built.
I missed that the change had already occurred. Carry on :)
Also, unless I'm misunderstanding something, the environment group doesn't handle cases where someone installs Workstation, the removes pieces of what we consider "core" functionality. At that point they are no longer running Workstation. (I'm not sure we have a good handle on that overall anyway, but removing the current Requires is fairly pointless.)
Right, I wasn't clear on whether we'd settled on this being mandatory functionality for calling it Workstation. If we did, then the fedora-release-workstation package should absolutely have this dep.
Of course, this approach has the same issue as this patch does, which is that it will only ensure that this new package is added to the Workstation upgrades and not to standard upgrades...
I still don't think that is bad, given that is the entire reason for the patch in the first place.
This was more a concern over the 'opt-in/opt-out' argument. I frankly would prefer it to be opt-out if we could manage it, because it's useful functionality that frankly only a very small number of people would want to disable. But since we have a technical limitation here rather than a policy disagreement, I'm going to stop talking about this topic, I think.
On Mon, Oct 6, 2014 at 8:48 AM, Stephen Gallagher sgallagh@redhat.com wrote:
On Mon, 2014-10-06 at 08:30 -0400, Josh Boyer wrote:
On Mon, Oct 6, 2014 at 8:21 AM, Stephen Gallagher sgallagh@redhat.com wrote:
Just a bit of an update; the new upgrade plan should be able to resolve this issue without the patch (and also in a way that is likely acceptable to all groups).
We can remove the explicit Requires: NM-captive-portal-fedora from both gnome-shell and fedora-release workstation, because the new 'fedup --network 21 --product=workstation' command will automatically install it as long as it's part of the @^workstation-product-environment group in comps (which a quick inspection shows is not currently the case but is a two-line change that I will submit right now).
I don't see a need to remove it from fedora-release-workstation now that it is already in and built.
I missed that the change had already occurred. Carry on :)
Yeah, only the change in fedora-release-workstation though. The Requires is still in gnome-shell. I'd like to remove it but given the rather long discussions I didn't feel it was quite kosher to do so at the moment.
Also, unless I'm misunderstanding something, the environment group doesn't handle cases where someone installs Workstation, the removes pieces of what we consider "core" functionality. At that point they are no longer running Workstation. (I'm not sure we have a good handle on that overall anyway, but removing the current Requires is fairly pointless.)
Right, I wasn't clear on whether we'd settled on this being mandatory functionality for calling it Workstation. If we did, then the fedora-release-workstation package should absolutely have this dep.
I think the Workstation WG feels it's mandatory.
Of course, this approach has the same issue as this patch does, which is that it will only ensure that this new package is added to the Workstation upgrades and not to standard upgrades...
I still don't think that is bad, given that is the entire reason for the patch in the first place.
This was more a concern over the 'opt-in/opt-out' argument. I frankly would prefer it to be opt-out if we could manage it, because it's useful functionality that frankly only a very small number of people would want to disable. But since we have a technical limitation here rather than a policy disagreement, I'm going to stop talking about this topic, I think.
Ditto :)
josh
Hi
On Mon, Oct 6, 2014 at 8:21 AM, Stephen Gallagher wrote:
Another option would be to take advantage of the new 'Recommends:' dependencies in RPM, but there are two issues with this:
- I don't know if yum/fedup supports this yet
No. It doesn't. This won't work.
Yum doesn't support soft dependencies and likely never will. libsolv does support soft dependencies but dnf doesn't expose it and this is unlikely to be done in the timeframe you want even with FESCo exception in place. In addition to that, fedup uses yum only to download packages and then runs rpm directly which ignores soft dependencies entirely
desktop@lists.fedoraproject.org
-
Dennis Gilmore -
drago01 -
Josh Boyer -
Matthew Miller -
Matthias Clasen -
Owen Taylor -
Rahul Sundaram -
Stephen Gallagher