#1737 Proposal: i686 SIG needs to be functional by F27 release date or we drop i686 kernel from F28
Closed: Fixed 2 years ago Opened 3 years ago by mattdm.

See https://fedoraproject.org/wiki/Changes/Stop_Building_i686_Kernels and
discussion at this message (and that whole thread) and

Proposal: accept this change for F28 if that SIG is not deemed functional by FESCo at F27 release time.

Criteria for "Functional" could include:

  • % of i686 bugs triaged in a reasonable time¹
  • % of i686 bugs actually fixed
  • has regular meetings (at least every four weeks?²)
  • Has a more than N regular members³
  1. (7 days from filing? I'm not sure what is a fair standard.)
  2. (With some quorum?)
  3. Like, more than "one"?

Metadata Update from @maxamillion:
- Issue tagged with: meeting

3 years ago

There's a lot of unclear criteria here. I'm -1 until we discuss and come to agreement.

I will note that I do not believe this suggestion should somehow impact the existing approach the Fedora kernel team has been taking with i686 builds.

FESCo Meeting 2017-07-21

  * AGREED: Proposal: Request criteria for what a "functional SIG" means
    in a measurable way (+1:5, +0:0, -1:0)  (maxamillion, 17:02:57)

I was on Holiday last week. Just to chime in, I am honestly not sure any of the sigs is fully functional. I do not believe we should apply any stricter criteria to a 32 bit x86 sig as we do for any other sigs. I am not sure how you could even determine some of the criteria was met. it would require significant effort in triaging bugs and issues at the least that is not currently done at all. if we drop the 32 bit x86 kernel we will have to drop all the 32 bit x86 deliverables. it would only remain as a means to provide multilib support. unless we dropped multilib also. we could in theory ship 32 bit x86 containers, something we do not do today, but it would require significant effort to change how we make the base images, as they require a kernel on the arch to work.

In today's FESCo meeting, we decided to defer the vote on this ticket until next week, due to lack of a quorum.

I still haven't seen any criteria defined. -1

I was hoping that someone more close to the issue would make those more concrete. It seems like the best way would be for the i686 SIG to propose what seems reasonable to them, have FESCo okay that, and then report back on whether they were able to meet that goal.

In Friday's FESCo meeting, it was decided that we will give the 32-bit x86 SIG two weeks to come up with their criteria for what a "functional SIG" means, and come back to FESCo for approval, and if they don't, we will drop i686 kernels for F28.

Adding to the meeting agenda for today's (2017-08-18) FESCo meeting at 16:00 UTC.

We discussed it in the meeting and agreed to extend the deadline for three more weeks, so that we can start a i686 SIG discussion on devel list and hopefully get a SIG formed at Flock. (kalev, 16:11:03)


Metadata Update from @kalev:
- Issue untagged with: meeting

3 years ago

Hello, revered members of FESCo!

I don't know if this issue is going to be discussed at the next meeting (9/8/17?), but I wanted to post our proposal for what "Functional" means. First, I want to make sure that we are all on the same page with regards to the scope of the issue. As has been discussed elsewhere, continued support for x86 software is still recognized as being a valuable feature of Fedora. The question is specifically about support for x86 hardware, especially the kernel and boot components. Therefore, we see that the way the SIG can help address the immediate needs of the community is to:

  • be responsible for defining the minimum hardware requirements
  • be a primary resource (hardware and warm bodies) for debugging x86-related boot, kernel, driver, and instruction-set related issues
  • help with testing, especially of boot and kernel components
  • help triage x86-related issues in Bugzilla, including interfacing with upstream projects to:
    • make them aware of bugs
    • liaise between upstream and the Fedora users seeing the problem
    • gently and respectfully advocate to have these bugs addressed

To that end, we propose the following metrics for a functional SIG:

  • Members respond to mailing lists in a reasonable amount of time(2-3 days?). Specifically, the following lists:
    • Fedora Users
    • Fedora Developers
    • x86 SIG
  • Maintain a tracker bug in Bugzilla of all x86-related bugs
  • Scan Bugzilla for x86-related bugs and help triage new issues in a reasonable amount of time (1-2 weeks?)
  • Test boot and install media for x86 targets

Any thoughts, comments, or suggestions are appreciated. If our proposal is not sufficient, we do ask for an opportunity to address any deficiencies. Thanks for your time!

Metadata Update from @bowlofeggs:
- Issue tagged with: meeting

3 years ago

This issue will be discussed in tomorrow's FESCo meeting, 2017-09-08 at 16:00:00 UTC in #fedora-meeting on Freenode.

Great - I will do my best to attend. Unfortunately, I have a must-attend meeting scheduled to end at 16:00:00 UTC, which may run over. (yay corporate life).

We discussed this during today's meeting, and we agreed to approve the functional SIG definition proposed by @jsbackus, with two caveats:

  1. If the kernel team experiences build issues, i686 will be ExcludeArched with a block to FE-ExcludeArch-x86 until the i686 SIG can address them.
  2. We would like to see a hardware support detail soon (for example, will PAE be supported?)

Metadata Update from @bowlofeggs:
- Issue untagged with: meeting

3 years ago

Great! Thanks for giving us this chance!

I'm still catching up on the meeting (sorry for not being able to make it), but we agree to the caveats as listed above. We will hash out the details of minimum hardware support soon. And no, we've decided to drop PAE support. We will reach out to the kernel team and let them know.

Metadata Update from @maxamillion:
- Issue tagged with: meeting

3 years ago

Any reason this still has the "meeting" keyword tagged back on it -- is there something that needs to be discussed in today's meeting?

@jsbackus as I said on the kernel list, dropping PAE is more involved than just turning it off in the kernel. You will need to work with the anaconda team to sort out impacts to anaconda and lorax.

2017-09-15 FESCo Meeting:

#agreed Revisit i686 SIG criteria has been met at first FESCo meeting after Final Freeze (+1:6, -1:0, +0:0)

Metadata Update from @maxamillion:
- Issue untagged with: meeting

3 years ago

Metadata Update from @sgallagh:
- Issue tagged with: meeting

2 years ago

Unfortunately, I won't be able to step away from work to make the meeting. If you need any input from us, please let me know and I'll try to get a response to you beforehand. Thanks!

@jsbackus In particular, can you assert and provide evidence that the guidelines you set down are being met and that the SIG is active and responsive?

Fair question!

We've set up an e-mail list and list members are responsive to new posts. We've set up a blocker bug to help us track issues that need attention. There are a handful of issues in BZ that we've helped shepherd to resolution, including helping with testing/verification in some cases. We have also made an effort to respond to i686-related questions on the user mailing list.

We also coordinated with the kernel team to deprecate PAE support, which was a concern of theirs. I made an attempt to initiate coordination with the Anaconda team, but I suspect my e-mail got lost in the 'moderation bin', and I haven't followed up, but I will do so.

We started on defining a minimum set of hardware, including ensuring that we had the actual hardware available for testing. We will complete this in the near future.

We established a list of window managers that will continue to support 32 bit architectures for the foreseeable future. We need to migrate this to the wiki to make it official.

We keep an eye out for FESCo requests, and respond to them when they happen. :grin:

Where we are deficient:
I've dropped the ball on a few items, including coordinating with the Anaconda team and migrating information from discussion to wiki.
We need to be more proactive about trawling BZ for i686-related issues.
* I haven't been as active as I need to be due to unexpected increase in workload.

Hopefully this is helpful. I can try to dig up more specific details, if you need me to.


AGREED: i686 SIG is certified functional and will be responsible for i686-specific issues (+6, 0, -0) (sgallagh, 16:10:33)

Metadata Update from @sgallagh:
- Issue close_status updated to: Fixed

2 years ago

@sgallagh Can #1748 be closed as Won't Fix now?

Login to comment on this ticket.