#1469 i686 as a non-blocking architecture

Created 2 years ago by jwboyer
Modified 2 years ago

= phenomenon =

i686 is becoming less and less relevant to both our developer set and our user base. Perhaps it is time to stop blocking releases on i686 images functioning properly.

= background analysis =

https://lists.fedoraproject.org/pipermail/devel/2015-August/213118.html

Also, Matthew Miller has slides illustrating decreasing (or at best flat) i686 usage over the past several releases.

= implementation recommendation =

If i686 boots and works, ship it. If it doesn't, drop the images and ship without them.

Also, I believe none of the Editions really wants i686 images at any rate so continuing to build and ship them seems somewhat silly.

I would prefer if we could discuss this at the meeting on August 26th, as I will be unavailable for this week's meeting due to a conference.

This proposal doesn't make for much less work for anyone. If we're going to treat i686 media as second-class, let's just do it. If we have to build the media and test it before deciding not to block on it being broken, that's still putting in a lot of effort on the release engineering and QA sides without any clear benefit.

I'd prefer the following counter-proposal: Ask each of the Editions and spins individually if they want a blocking i686 medium. Then only produce and test those that say "yes". This will likely result in a significant reduction in the compose and testing effort (and may help us get some of our compose time shortened).

In other words, I think it needs to be a boolean state: either i686 is blocking or it is not built. Anything in-between creates unnecessary work.

Replying to [comment:4 sgallagh]:

This proposal doesn't make for much less work for anyone. If we're going to treat i686 media as second-class, let's just do it. If we have to build the media and test it before deciding not to block on it being broken, that's still putting in a lot of effort on the release engineering and QA sides without any clear benefit.

It requires no more effort from rel-eng than today, given that they're already doing this. I would agree that it is not a reduction in effort for QA necessarily.

I'd prefer the following counter-proposal: Ask each of the Editions and spins individually if they want a blocking i686 medium. Then only produce and test those that say "yes". This will likely result in a significant reduction in the compose and testing effort (and may help us get some of our compose time shortened).

We kind of did this with ARM for f21 and it didn't work. Workstation explicitly said it didn't want an ARM image and one was produced anyway. This was still the case for f22 as well. Hopefully we're at the point where we can actually do this kind of deviation now.

In other words, I think it needs to be a boolean state: either i686 is blocking or it is not built. Anything in-between creates unnecessary work.

That is mostly fine with me, though I will note that spins which request i686 images will be on the hook for making sure they work. We don't block the release for spins other than the KDE spin anyway. In the event KDE requests an i686 image and it is broken, I would still prefer to ship without it, which is where my original proposal comes in.

Replying to [comment:4 sgallagh]:

This proposal doesn't make for much less work for anyone. If we're going to treat i686 media as second-class, let's just do it. If we have to build the media and test it before deciding not to block on it being broken, that's still putting in a lot of effort on the release engineering and QA sides without any clear benefit.

I don't understand why "building the media" requires any human effort at all. How is that more complicated than a cron job?

But yes, making the media targets per-spin/edition would make the issue go away entirely; if nobody wanted an i686 image one would not be produced. Assuming their construction is automated then the whole discussion seems pretty trivial to me.

For the record, at the Server SIG meeting, we agreed on the following statement: "Starting with Fedora 24, Fedora Server Edition will not ship or block on any media that installs on an i686-only system as a primary architecture."

Replying to [comment:6 ajax]:

I don't understand why "building the media" requires any human effort at all. How is that more complicated than a cron job?

Sure, we could build them, but if we aren't testing them or commiting to fixing them then it could well be providing a broken or shoddy product, which IMHO is worse than commiting to not shipping it at all.

So I see this was tagged with the meeting keyword even though I asked for it to be discussed on August 26th. If you do wind up talking about it today, I won't be able to attend. I am +1 for any proposal that doesn't result in us blocking release on i686.

Oh, sorry. I forgot this was requested for Aug. 26th.

I put it on the agenda since we got feedback from Server and Workstation.

Workstation: "The Workstation WG would prefer to keep i686 if and only if someone is actively maintaining the kernel, otherwise they will drop it"

Given that no one has stepped up to maintain i686 in the community, it looks like we're mostly in agreement to drop it from the Editions' media.

I am not able to attend meeting today so +1 to what majority will decide for this ticket. Also, if there will be no i686 kernel then we will not be having any product released for i686 so this should be then non-blocking architecture.

What is the status of EFI_MIXED support in grub and shim?

Replying to [comment:13 rishi]:

What is the status of EFI_MIXED support in grub and shim?

I believe it is on Peter Jones' TODO list. I'm not sure why you are asking that here though. It really has no bearing on the state of i686 itself and at best is an enabler for a use case we currently do not support (32-bit UEFI with a 64-bit kernel.)

  • Discussion postponed until next week to wait for more feedback. (sgallagh, 18:13:58)

Replying to [comment:14 jwboyer]:

Replying to [comment:13 rishi]:

What is the status of EFI_MIXED support in grub and shim?

I believe it is on Peter Jones' TODO list. I'm not sure why you
are asking that here though. It really has no bearing on the state
of i686 itself and at best is an enabler for a use case we currently
do not support (32-bit UEFI with a 64-bit kernel.)

I am asking because it affects the Intel tablets (that Bastien is interested in) with a 64-bit capable CPU but only 32-bit firmware. Although, I don't know if the Workstation WG has an "official" position on those.

Replying to [comment:16 rishi]:

Replying to [comment:14 jwboyer]:

Replying to [comment:13 rishi]:

What is the status of EFI_MIXED support in grub and shim?

I believe it is on Peter Jones' TODO list. I'm not sure why you
are asking that here though. It really has no bearing on the state
of i686 itself and at best is an enabler for a use case we currently
do not support (32-bit UEFI with a 64-bit kernel.)

I am asking because it affects the Intel tablets (that Bastien is interested in) with a 64-bit capable CPU but only 32-bit firmware. Although, I don't know if the Workstation WG has an "official" position on those.

Great, but that has nothing to do with this proposal. 32-bit firmware with a 64-bit kernel is currently unsupported. If it is made to work, great. If not, nothing changes. It is irrelevant to this discussion. Put another way, if the only way to use such hardware is through i686 only, then you would need to weigh how relevant that hardware is to the Fedora project as an i686 only machine. Frankly, it isn't very relevant today.

I am very opposed to holding up discussion and decision on the current proposal based on something that is currently unsupported and unrelated not being available.

Fedora will ship no i686/32-bit x86 install media in Fedora 24 as a primary/blocking deliverable.

Replying to [comment:18 rishi]:

Fedora will ship no i686/32-bit x86 install media in Fedora 24 as a primary/blocking deliverable.

We should probably remind people of this now that F24 is in full swing.

Yeah, a post to devel-announce and shall we stop making/testing the i686 images in rawhide now?

Replying to [comment:20 kevin]:

Yeah, a post to devel-announce and shall we stop making/testing the i686 images in rawhide now?

Maybe? We should probably bring this up in open floor in today's meeting.

Login to comment on this ticket.