#1539 Are 32-bit upgrades to Fedora 24 release blocking? Supported?
Closed None Opened 3 years ago by adamwill.

FESCo decided in [https://fedorahosted.org/fesco/ticket/1469 #1469] that 32-bit media are no longer considered release-blocking for Fedora 24. However, AFAICT, the question of upgrading existing 32-bit installs was not considered.

We have release criteria for upgrades, i.e. some upgrade issues are considered release blocking. Say we found a bug that violates the upgrade criteria, but affects 32-bit systems only. Is that a release blocker bug? Do we want to 'support' upgrades to 32-bit F24 at all?

Thanks!


Putting this on tomorrow's meeting agenda.

Unsurprisingly, I'm not in favor of blocking on this. I can see argumentation for it, but I'm still not in favor of it.

I forgot to note my own opinion here, which is also not to block on it. If i686 has upgrade bugs, let them get worked out in their own time if someone cares enough.

With about 20% of the yum/dnf queries still coming from x86_64, I'm hesitant to do this with a hard stop at the next release. I think we'd be better marking it deprecated for at least one release. (Maybe two, but I can see the argument for one, since if F25 has something broken, F24 will still be supported at that time and there will be ~7 months after that for users to figure something out.)

Replying to [comment:4 mattdm]:

With about 20% of the yum/dnf queries still coming from x86_64,

You mean i686?

I'm hesitant to do this with a hard stop at the next release. I think we'd be better marking it deprecated for at least one release. (Maybe two, but I can see the argument for one, since if F25 has something broken, F24 will still be supported at that time and there will be ~7 months after that for users to figure something out.)

I'm hesitant to block on something that various groups have already said they are not treating as blocker and not going to prioritize. Pretending otherwise is setting multiple groups up for failure.

Replying to [comment:5 jwboyer]:

Replying to [comment:4 mattdm]:

With about 20% of the yum/dnf queries still coming from x86_64,
You mean i686?

Sheesh, clearly I have a brain problem.

Yes.

I even had written 32 bit and then thought about it and changed it to distinguish from ARM 32 bit (up to almost 5%, btw.)

I'm hesitant to block on something that various groups have already said they are not treating as blocker and not going to prioritize. Pretending otherwise is setting multiple groups up for failure.

I guess that's one way to look at it. Another way is: here's some data on our users that maybe those groups were assuming to be lower, and with this information, maybe they want to prioritize a little differently.

Replying to [comment:7 mattdm]:

Replying to [comment:5 jwboyer]:

Replying to [comment:4 mattdm]:
I'm hesitant to block on something that various groups have already said they are not treating as blocker and not going to prioritize. Pretending otherwise is setting multiple groups up for failure.

I guess that's one way to look at it. Another way is: here's some data on our users that maybe those groups were assuming to be lower, and with this information, maybe they want to prioritize a little differently.

20% as a number isn't informative enough. Could you elaborate on what exactly it is reflecting?

E.g. if that is 20% of all queries, does that includes queries for EOL releases? Is that 20% over the lifetime of the project? If that 20% is only including current non-EOL releases, is it growing or shrinking or staying static from release to release? How does that correlate with new i686 media download percentages?

People that use i686 aren't going to just throw it away if it's working, which is very likely what that 20% is reflecting. However, that doesn't mean we are committed to support aging hardware indefinitely. Instead, it means that people wishing to use such hardware will need to invest more to make sure it continues to work.

installer downloads in the last two years
download-graph.png

update server connections going back more years
updates-graph.png

Replying to [comment:8 jwboyer]:

20% as a number isn't informative enough. Could you elaborate on what exactly it is reflecting?

See graphs attached. There was a downward trend in update server connections but now it's leveled off. And, installer downloads over the past two years are the same 20%.

I don't have a breakdown of update server connections by release and arch, though -- I've asked Smooge for an update on that.

(Also of note, the big drop in i686 late 2014 is a mysterious data anomaly where F12, F13, F14, and F15 numbers all decrease by 97.3% in one day. EPEL 6 drops too that day, but not by as much.)

All that said, if we actually don't have the resources to support i686 systems, we're not really doing users any favors by claiming otherwise. And as far as I know, no one stepped up after Josh's message last year https://lists.fedoraproject.org/pipermail/devel/2015-February/208368.html.

If we're going to do it:

a) we should give people as much notice as possible and be as clear as possible about the reasons

b) we should go all the way and stop providing bootable i686 anything

c) and we should consider making i686 a secondary arch except for multilib.

mattdm: Is there any way to get the raw numbers (ie, not in a graph)?

Replying to [comment:12 jdulaney]:

mattdm: Is there any way to get the raw numbers (ie, not in a graph)?

I've promised Smooge that I'll be careful about making sure the raw numbers don't end getting misused to represent things they don't. Because we're not tracking individual machines in any way, and don't have any explicit opt-out census system, it's best to think of the Y axis in relative terms like I've shown here. (If anything, it probably underestimates older systems, as the count is definitely higher where there is always-on Internet, which probably correlates with more newer computers.)

AGREED: Upgrade issues unique to ix86 do not block the release (+6, 0, -0) (sgallagh, 17:55:16)

Login to comment on this ticket.

Metadata