----- Original Message -----

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1

On 09/24/2014 12:22 PM, Jaroslav Reznik wrote:

...

----- Original Message ----- There has been some discussion in various forums lately about how we will handle fedup upgrades from Fedora 20 to Fedora 21 products.

Several suggestions have been made that warrant discussion:

• Upgrades from Fedora 20 remain non-productized. They pick up

fedora-release-standard and upgrade only their existing packages. * Upgrades from Fedora 20 become Fedora Workstation systems and have the appropriate environment group installed on them. This mechanism will not remove any existing packages. * Fedup should provide a selection for which Product (or non-productized) version to upgrade to.

I am personally opposed to forcing all upgrades to become Fedora Workstation (even if in general the majority of existing deployments are desktop/laptop machines).

I think either the first option (easy) or the last option (requiring fedup changes) will be preferable. In the selectable case, I think that fedup should operate as a non-productized upgrade unless otherwise specified at the command-line. If we pass --server, --workstation, --cloud, it should upgrade existing packages as well as installing the complete set of the @^fedora-$PRODUCT-environment comps environment group.

...

Maybe we can go with first option and say, upgrades to products are not supported, please reinstall. It's new beginning and say non-productized update support will be gone in F22 timeframe and only productized updates will be allowed.

Well, that cannot be the case, since it would leave the users of Spins completely out in the cold. That's something we've asserted numerous times now that we won't do.

Ah, you're right. On the other hand I think all spins are somehow desktop related (at least now), so moving spins to use workstation as the base is probably desirable. Actually, it was one of the ultimate plans for Workstation.

Jaroslav

...

...

In Czech we say "Když se kácí strom, létají třísky" - Google Translate is your friend :).

...

Jaroslav

...

-- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

-----BEGIN PGP SIGNATURE----- Version: GnuPG v1

iEYEARECAAYFAlQi8BAACgkQeiVVYja6o6PwsACgjaekfg/iUEHIjzCDtX+HlSku 3q4AmgJySKNxCkF3a2o8N7VINCd3I9dx =ODjr

-----END PGP SIGNATURE-----

devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

----- Original Message -----

Hi

On Wed, Sep 24, 2014 at 12:35 PM, Jaroslav Reznik wrote:

Ah, you're right. On the other hand I think all spins are somehow desktop related (at least now), so moving spins to use workstation as the base is probably desirable

No. It is not. Workstation is GNOME based. Most spins are for alternative desktop environments

Well, initial plan was other desktop environments are going to use workstation as base. It definitely makes sense, we want to have a base for all desktops (aka having same underlaying technology aka GStreamer, UDisks) and it would simplify upgrades a lot.

Also I still hope we will overcome all "GNOME", "KDE", "BLABLA" based thing and will ship Workstation product that serves it's purpose, showing the best open source software. First step with inclusion of Qt and KDE libs is being done.

But it's another discussion.

Jaroslav

Rahul

-- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

On Wed, Sep 24, 2014 at 6:22 PM, Jaroslav Reznik jreznik@redhat.com wrote:

----- Original Message -----

...

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1

There has been some discussion in various forums lately about how we will handle fedup upgrades from Fedora 20 to Fedora 21 products.

Several suggestions have been made that warrant discussion:

• Upgrades from Fedora 20 remain non-productized. They pick up

fedora-release-standard and upgrade only their existing packages.

• Upgrades from Fedora 20 become Fedora Workstation systems and have

the appropriate environment group installed on them. This mechanism will not remove any existing packages.

• Fedup should provide a selection for which Product (or

non-productized) version to upgrade to.

I am personally opposed to forcing all upgrades to become Fedora Workstation (even if in general the majority of existing deployments are desktop/laptop machines).

I think either the first option (easy) or the last option (requiring fedup changes) will be preferable. In the selectable case, I think that fedup should operate as a non-productized upgrade unless otherwise specified at the command-line. If we pass --server,

• --workstation, --cloud, it should upgrade existing packages as well as

installing the complete set of the @^fedora-$PRODUCT-environment comps environment group.

Maybe we can go with first option and say, upgrades to products are not supported, please reinstall. It's new beginning and say non-productized update support will be gone in F22 timeframe and only productized updates will be allowed.

That's a lame excuse really. "Please reinstall" is more or less telling users "go away". So that's not really an option (there aren't even any technical reasons for it).

2014-09-30 15:04 GMT+02:00 Petr Hracek phracek@redhat.com:

In RHEL we are using preupgrade-assistant [1] which does this work. If user write a check script then it will inform user that upgrade is not supported. The check script can also inform user that e.g. mariadb changed structure and it's required to execute a convert script or whatever.

Currently now preupgrade-assistant is not available in Fedora. I discussed with Honza Horak (team lead of databases) about this issues and can be used in this case.

There is only one issue. Each package maintainer should create own subpackage with check script which should be used on Fedora.

No thanks. You should suggest a more targeted approach than adding such a burden to package maintainers.

And I think that this is a bit problematic. From time point of view

[1] https://github.com/phracek/preupgrade-assistant

...

In Czech we say "Když se kácí strom, létají třísky" - Google Translate is your friend :).

Jaroslav

...

-----BEGIN PGP SIGNATURE----- Version: GnuPG v1

iEYEARECAAYFAlQi7kYACgkQeiVVYja6o6OMSACgjZqFxjISnfEhVVSXWLs7HENf cIwAoK6e/Dp1uLvVX1feUr4gouTwhKsd =U4A7

-----END PGP SIGNATURE-----

devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

-- Best regards / S pozdravem Petr Hracek

-- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

No, definitely not.

preupgrade-assistant is only the tool which informs user or admin what was change against the newest version and recommend actions for inplace upgrades. But as I mentioned. Currently now it's not available in Fedora.

Preupgrade-assistant doesn't modify system at all.

On 09/30/2014 03:50 PM, Rahul Sundaram wrote:

Hi

On Tue, Sep 30, 2014 at 9:04 AM, Petr Hracek wrote:

In RHEL we are using preupgrade-assistant [1] which does this work.
If user write a check script then it will inform user that upgrade
is not supported.
The check script can also inform user that e.g. mariadb changed
structure
and it's required to execute a convert script or whatever.

Currently now preupgrade-assistant is not available in Fedora.
I discussed with Honza Horak (team lead of databases) about this
issues
and can be used in this case.

So preupgrade was replaced by fedup in Fedora and now you want to introduce another tool called preupgrade-assistant which is entirely different? Can't you folks get together and focus on one tool, whatever that is?

Rahul

Preupgrade assistant performs assessment of the system from the "upgradeability" point of view. It is based on OpenSCAP engine. It reports potential risks for in-place upgrading system. fedup can call our API. For sure.

That's all.

On 09/30/2014 03:59 PM, Rahul Sundaram wrote:

HI

On Tue, Sep 30, 2014 at 9:57 AM, Petr Hracek wrote:

No, definitely not.

preupgrade-assistant is only the tool which informs user or admin
what was change against the newest version and recommend actions
for inplace upgrades.
But as I mentioned. Currently now it's not available in Fedora.

So why can't this functionality be part of fedup exactly?

Rahul

Or better say, fedup remains as tool for upgrades.

On 09/30/2014 03:57 PM, Petr Hracek wrote:

No, definitely not.

preupgrade-assistant is only the tool which informs user or admin what was change against the newest version and recommend actions for inplace upgrades. But as I mentioned. Currently now it's not available in Fedora.

Preupgrade-assistant doesn't modify system at all.

On 09/30/2014 03:50 PM, Rahul Sundaram wrote:

...

Hi

On Tue, Sep 30, 2014 at 9:04 AM, Petr Hracek wrote:

In RHEL we are using preupgrade-assistant [1] which does this work.
If user write a check script then it will inform user that
upgrade is not supported.
The check script can also inform user that e.g. mariadb changed
structure
and it's required to execute a convert script or whatever.

Currently now preupgrade-assistant is not available in Fedora.
I discussed with Honza Horak (team lead of databases) about this
issues
and can be used in this case.

So preupgrade was replaced by fedup in Fedora and now you want to introduce another tool called preupgrade-assistant which is entirely different? Can't you folks get together and focus on one tool, whatever that is?

Rahul

-- Best regards / S pozdravem Petr Hracek

On Wed, 24 Sep 2014 17:14:40 -0400 Simo Sorce simo@redhat.com wrote:

On Wed, 24 Sep 2014 12:27:04 -0400 Matthew Miller mattdm@fedoraproject.org wrote:

...

On Wed, Sep 24, 2014 at 12:16:06PM -0400, Stephen Gallagher wrote:

...

I think either the first option (easy) or the last option (requiring fedup changes) will be preferable. In the selectable case, I think that fedup should operate as a non-productized upgrade unless otherwise specified at the command-line. If we pass --server,

• --workstation, --cloud, it should upgrade existing packages as

well as installing the complete set of the @^fedora-$PRODUCT-environment comps

I'm in favor of either of these. I'd suggest aiming for the last but falling back to the first if it's not working in the beta?

+1

Sounds reasonable, but might be best to talk to the fedup maintainer and see how on-board with those changes he is. ;)

kevin

On 09/24/2014 11:28 AM, Kalev Lember wrote:

Fourth option might be to make all installations that have gnome-shell installed become Workstation, and leave others non-productized.

This is hardly a guarantee. I have several servers that get a default Fedora install and I don't bother removing X and friends because the reduced drive usage is meaningless.

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1

On Wed, 24 Sep 2014 18:29:11 +0200 Reindl Harald h.reindl@thelounge.net wrote:

Am 24.09.2014 um 18:16 schrieb Stephen Gallagher:

...

There has been some discussion in various forums lately about how we will handle fedup upgrades from Fedora 20 to Fedora 21 products.

Several suggestions have been made that warrant discussion:

• Upgrades from Fedora 20 remain non-productized. They pick up

fedora-release-standard and upgrade only their existing packages.

• Upgrades from Fedora 20 become Fedora Workstation systems and

have the appropriate environment group installed on them. This mechanism will not remove any existing packages.

• Fedup should provide a selection for which Product (or

non-productized) version to upgrade to.

I am personally opposed to forcing all upgrades to become Fedora Workstation (even if in general the majority of existing deployments are desktop/laptop machines).

I think either the first option (easy) or the last option (requiring fedup changes) will be preferable. In the selectable case, I think that fedup should operate as a non-productized upgrade unless otherwise specified at the command-line. If we pass --server, --workstation, --cloud, it should upgrade existing packages as well as installing the complete set of the @^fedora-$PRODUCT-environment comps environment group

while i talk here only about YUM instead of "fedup" it may also be a matter of dependencies at the end:

i would strongly prefer "non-productized" because i have around 30 machines upgraded now from F9 to F20 with YUM and they are all strongly customized all sort of servers, workstations and all of them are stripped-down setups with no unused package installed

pull a desktop on a nameserver with 291 packages - no thanks :-)

for me the products are a nice thing for a lot of users to get sane combinations targeting the needs, on the other hand many server admins likely want to continue with minimal installs and add additional packages as needed (we do that with meta-packages only defining dependencies) because it don't happen often enough to install a phyiscal machine from scratch compared to clone the golden master virtual machine

I have updated a few machines by running "yum --releasever=21 install fedora-release" then "yum distro-sync" and not had any issues. As I understand this thread it is soley about what to do in the case of using fedup only. in which case we need to setup some things in mirrormanager and do some testing and see what happens. note that we may not be able to use the fedora-install-21 prefix as the install trees all have a prefix already assigned

Dennis

On Wed, Oct 01, 2014 at 04:28:22PM -0400, Stephen Gallagher wrote:

The thing to note is that in all scenarios, the user *MUST* fully update their F20 system first, or the results will be undefined and could be unpleasant. We need to spell this out very clearly to our upgrading users.

Here's what I'm thinking...

Converting from vanilla to and from productized Fedora is a separate issue from upgrading. It's something that someone might want to do at any point, and it's something that we'll want to have beyond just the F21 release.

I can see the convenience value of letting people check a box or give a flag at the F20->F21 upgrade point. I wish we had thought of that several months ago, but I don't think anyone did (or we dropped it if it were mentioned, sadly). At this point, since the fedup maintainers aren't sold and we're working on validating the beta already, *and* because the upgrade-to-convert situation is a one time thing, I think we should put our efforts into the convert-at-any-time situation.

On Wed, 2014-10-01 at 16:28 -0400, Stephen Gallagher wrote:

On Wed, 2014-09-24 at 12:16 -0400, Stephen Gallagher wrote:

...

There has been some discussion in various forums lately about how we will handle fedup upgrades from Fedora 20 to Fedora 21 products.

Several suggestions have been made that warrant discussion:

1. Upgrades from Fedora 20 remain non-productized. They pick up

fedora-release-standard and upgrade only their existing packages.

I've had a number of conversations with the yum/dnf and fedup people over the last week. The tl;dr version: option 1) is the only realistic option.

So, a bit more contributing detail:

First, the Products have both a minimal set and a default set of functionality that they want to have exposed if that Product is installed. What we've decided that this means is that, barring explicit influence, anyone who is installing Fedora Workstation or Fedora Server should be getting the default set of functionality and can later (or in a kickstart file) trim it back.

Without changing the fedup package in Fedora, we could do upgrades to each of the Products or non-productized versions by providing on F20 a do-nothing fedora-release-[standard|cloud|server|workstation] file that in F21 has explicit requirements on any of the packages necessary to reach the minimal set of functionality. We can't force it to the default set (without allowing RPM soft dependencies, which is not currently supported or well-tested in Fedora), so upgrading through this path wouldn't guarantee the preferred result state (particularly for Workstation, which wants to have a certain set of common applications installed by default). Furthermore, it makes the upgrade process more complicated because it would require the user to manually install 'fedora-release-standard' in order to get the non-productized experience and they would not be able to upgrade *at all* without selecting one of them.

Fedora officially only supports upgrades from a *fully-upgraded Fedora* to the next version, so we could work around this by adding a temporary explicit Requires: fedora-release-standard on the F20 fedora-release package, thereby forcing all upgrades to be non-productized. This is my recommended approach as it requires only a single change (the added Requires:) to fedora-release to make it work. The end-result of this upgrade is a system that is just a newer version of whatever DIY set of packages the previously-F20 system was running.

It's also possible that we could rig up a selectable approach by creating a full set of empty fedora-release-* packages and arranging it so that fedora-release-standard satisfied the upgrade requirement if it wasn't specified, but this requires us to make sure that the automatic dependency-resolution for all of yum, dnf, gnome-software, yumex and apper all selects the correct default. I know for a fact that at least yum and dnf follow different resolution patterns, so while it could be possible, it would be a nasty hack relying on internal knowledge of the tools. That seems somewhat fragile to me, but it could be done if we strongly want it.

The thing to note is that in all scenarios, the user *MUST* fully update their F20 system first, or the results will be undefined and could be unpleasant. We need to spell this out very clearly to our upgrading users.

Yet one more change. A number of folks from the Workstation, Server and fedup teams got together in #fedora-workstation today and hashed out a new plan. We decided that it was fine to modify fedup and that it was also acceptable to force the user to make a choice at upgrade time.

To that end, fedup will grow a new mandatory option: --product. It will take one of four arguments: "standard" (non-productized), "server", "workstation" or cloud.

For each of the Products, fedup will inject the appropriate set of packages necessary to make the resulting system contain a superset of the packages that one would get with a default installation of the selected Product. (In a technical sense, it would essentially be injecting "@^$PRODUCT-product-environment" onto the yum installation command to ensure that all of those packages are part of the transaction).

I have sent an email to the QA folks to get this arrangement added to the Beta Criteria, since that's our last chance to realistically test upgrades before release. So fixing this becomes a blocker to Beta.

On Fri, 2014-10-03 at 17:06 -0400, Owen Taylor wrote:

standard: choose this if none of the above apply; in particular choose this if you are using an alternate-desktop spin of Fedora

I'd add a comma right after "in particular."

Feedback from this wide audience appreciated. Would you know what option to pick?

Yes, it's clear.

I agree with Rahul that "standard" is not a great name for the nonstandard, non-productized upgrade, though. "Generic" is more descriptive anyway.

On Sat, Oct 4, 2014 at 1:27 AM, Matthew Miller mattdm@fedoraproject.org wrote:

On Fri, Oct 03, 2014 at 06:18:11PM -0500, Michael Catanzaro wrote:

...

I agree with Rahul that "standard" is not a great name for the nonstandard, non-productized upgrade, though. "Generic" is more descriptive anyway.

But vanilla is the most delicious.

But has no meaning that context for pretty much all non english languages.

Hi,

I agree with Rahul that "standard" is not a great name for the nonstandard, non-productized upgrade, though. "Generic" is more descriptive anyway.

I'm not sure it's worth repainting the bikeshed at this point, but during the alluded-to discussion a few alternative names came up that would have been better than fedora-release-standard:

1) fedora-release-nonstandard 2) fedora-release-custom 3) fedora-release-diy 4) fedora-release-noncompliant

and i'll just throw another out there now

5) fedora-release-respin

If we do want to change it, it should happen soon....

--Ray

On Fri, 2014-10-03 at 19:37 -0400, Ray Strode wrote:

I'm not sure it's worth repainting the bikeshed at this point, but during the alluded-to discussion a few alternative names came up that would have been better than fedora-release-standard:

1. fedora-release-nonstandard

That this was the first item on the list suggests that fedora-release-standard is not the right name. :) In fact, most of the names on your list are antonyms of "standard."

3. fedora-release-diy

Not a good name for spins. This sounds like Gentoo.

4. fedora-release-noncompliant

This one makes it sound like not running a product is a bad thing. Let's avoid this one.

All the other names are fine. I still like fedora-release-generic the best. My favorite color of paint is Myrtle Green. It's a nice color. [1]

Michael

[1] https://en.wikipedia.org/wiki/Shades_of_green#Myrtle_green

On Sat, 2014-10-04 at 12:46 -0400, Mike Pinkerton wrote:

On 3 Oct 2014, at 19:37, Ray Strode wrote:

...

I'm not sure it's worth repainting the bikeshed at this point, but during the alluded-to discussion a few alternative names came up that would have been better than fedora-release-standard:

1. fedora-release-nonstandard
2. fedora-release-custom
3. fedora-release-diy
4. fedora-release-noncompliant

The "nonstandard" and "noncompliant" names seem a bit pejorative.

However, fedora-release-custom and fedora-release-diy (do-it- yourself) and fedora-release-pyop (pick-your-own-packageset) and fedora-release-byob (bring-your-own-blueprint) all have similar meanings to this US-English speaker, and all seem like reasonable choices, although the last three might require a parenthetical explanation for some folk.

Rehashing the conversation elsewhere, the problem with DIY and similar is that it doesn't make much sense in the context of Spins, which are non-productized but not particularly do-it-yourself.

Perhaps we should have just gone with 'fedora-release-nonproduct' like I originally suggested months ago...

Anyway, I don't really care what we pick, so long as it's decided in the next 24 hours so we can deal with the Obsoletes hoops and make sure it gets pushed out and into a test compose.

Hi

On Fri, Oct 3, 2014 at 4:57 PM, Stephen Gallagher wrote:

To that end, fedup will grow a new mandatory option: --product. It will take one of four arguments: "standard" (non-productized), "server", "workstation" or cloud.

When the discussion about the "standard" name came up earlier in fedora desktop list, one counter point was that standard isn't going to be very visible to users but if you are going to use that term in fedup, it becomes even more visible. Do you still want to not use "generic" here?

Rahul

Hi

On Fri, Oct 3, 2014 at 5:38 PM, Reindl Harald wrote:

"generic" is technical speak or for "normal" people outside IT at best has a negative context to "generica" and spam

It is not really technical. Generic is often used in other contexts by "normal" people: Ex: Generic drugs which means non branded.

- "standard" for the

ordinary user means "not specialized so likely the best decision for me"

Exactly the message Fedora doesn't want to send to its users. Thanks for confirming.

Rahul

Hi

On Fri, Oct 3, 2014 at 6:15 PM, Reindl Harald wrote:

"generic drugs" is the one thing nobody wants to have in context honestly

Not true but irrelevant anyway since I was just pointing out that generic is not a technical term.

why would you try to force somebody to a "prodcut setup"

if he can't give you an answer to the question "which"?

Noone is forcing anything since non productized variants are continued to be supported but the emphasis is on the products (whether you think it should be is a different discussion) and as you confirmed, the use of the term "standard" doesn't convey that to the user

Rahul

Hi

On Fri, Oct 3, 2014 at 6:34 PM, Reindl Harald wrote:

and *because* non productized variants are continued there should be no emphasis instead *equal options*

Fedora as a project has already discussed that extensively and decided otherwise. We are not really revisiting that discussion here.

Rahul

Am 04.10.2014 um 18:08 schrieb Jaroslav Nahorny:

...

Am 03.10.2014 um 23:57 schrieb Rahul Sundaram:

...

On Fri, Oct 3, 2014 at 5:38 PM, Reindl Harald wrote:

 "generic" is technical speak or for "normal" people outside IT at best
 has a negative context to "generica" and spam

I never heared about „generica” and seing the term „generic” I don't have any associations with spam

https://www.google.com/search?q=spam+generic+viagra there is even a SpamAssassin tag "DRUG_ED_GENERIC"

On 10/01/2014 10:28 PM, Stephen Gallagher wrote:

Fedora officially only supports upgrades from a*fully-upgraded Fedora* to the next version, so we could work around this by adding a temporary explicit Requires: fedora-release-standard on the F20 fedora-release package, thereby forcing all upgrades to be non-productized. This is my recommended approach as it requires only a single change (the added Requires:) to fedora-release to make it work. The end-result of this

I tried the upgrade during weekend. And I tried to simulate this requires during upgrade. The problem is that once you get fedora-release-standard, you will get other *-standard (e.g. firewalld-config-standard) and there is no way to switch -workstation (or other product) unless you use 'rpm --nodeps', which is pretty dirty hack.

If you use this Requires, then at the same time please provide users migration tool product2product. Or at least standard2product.