I opened the ticket, it is here: https://pagure.io/fesco/issue/1918
Thanks again Stephen for the suggestion. On Thu, Jun 21, 2018 at 9:46 AM, Gerald B. Cox <gb...@bzb.us> wrote: > Interesting... thanks Adam... but the way I read that is specifically > tailored to "release criteria", not > design/implementation guidelines - i.e. to me this says, don't hold up a > release because someone > screwed up and didn't conditionalize the process correctly. > > On Thu, Jun 21, 2018 at 9:38 AM, Adam Williamson < > adamw...@fedoraproject.org> wrote: > >> On Thu, 2018-06-21 at 12:08 -0400, Stephen Gallagher wrote: >> > On Thu, Jun 21, 2018 at 12:03 PM Gerald B. Cox <gb...@bzb.us> wrote: >> > >> > > >> > > >> > > On Thu, Jun 21, 2018 at 6:39 AM, Stephen Gallagher < >> sgall...@redhat.com> >> > > wrote: >> > > >> > > > >> > > > >> > > > >> > > > > I believe we're missing something fundamental here. If a >> > > > > program/service etc. requires specific hardware to work >> > > > > and it can't gracefully handle situations where that hardware is >> not >> > > > > present - it shouldn't be a default. >> > > > > >> > > > > The way to handle this (and other similar situations) is to take >> away >> > > > > the default status until it can handle >> > > > > situations where the hardware doesn't exist. This is systems >> > > > > programming 101 - and frankly I am a >> > > > > bit surprised it's a matter of debate. >> > > > > >> > > > > >> > > > >> > > > No one on this list is disagreeing that the defaults should not >> degrade >> > > > the system. I *do* think that your response is an overreaction: just >> > > > because software may have bugs on your hardware doesn't mean that >> it should >> > > > be turned off entirely. If it's causing problems for a small subset >> of >> > > > users, they can be manually disabled. >> > > > >> > > > These services provide CONSIDERABLE benefit on the hardware that >> supports >> > > > it. Removing that as a default for those systems would be a >> significant >> > > > regression. That's not an acceptable solution. >> > > > >> > > > Most of the people on this thread seem to agree: we can >> conditionalize >> > > > the defaults so it is either skipped or at least does not mark the >> service >> > > > as "failed" if the necessary hardware is not present. People are >> already >> > > > working on doing this. >> > > > >> > > >> > > Stephen, I'm not disputing the benefit - and I very much appreciate >> the >> > > fact that people are working to conditionalize the defaults. What I >> do >> > > disagree with is your characterization that this is a bug. >> > > It is working as it was designed - and the design is faulty - and it's >> > > pervasive. I've encountered THREE different processes that aren't >> properly >> > > conditionalized. That's definitely not a bug - that's a systemic >> issue. >> > > Yes, AMD processors are not as popular as Intel, but they do exist in >> > > considerable numbers and most definitely should be >> > > considered when things are implemented as defaults; additionally... >> > > obviously... not everybody uses SecureBoot. >> > > My comment regarding taking away default status was in regards to this >> > > lingering for years. >> > > I personally don't believe that is acceptable. If one can't figure >> out >> > > how to fix things like this in a timely manner, then there is a >> problem. >> > > >> > > >> > >> > Well, there was also a failure of escalation path here. If this was >> going >> > on for years without a resolution, why wasn't it raised on this list or >> to >> > FESCo a long time ago? Individual maintainers have their own priorities >> and >> > time constraints and don't always address every bug that comes their >> way. >> > >> > However, had it risen up the chain, it's possible a group like FESCo >> might >> > take note and set down some rules/requirements. As it is, I think it's >> > probably time right now to move this to a FESCo ticket and see what we >> can >> > do about it. Gerald, if you feel strongly about this issue, please file >> it. >> >> Note we already have a release criterion related to this: >> >> "All system services present after installation with one of the >> release-blocking package sets must start properly, unless they require >> hardware which is not present." >> >> That lets out the rngd and Intel vs. AMD cases, I guess - it is >> specifically written to do so, after we decided once that we didn't >> want to block the release on the rngd case or one like it - but it >> would cover the Secure Boot case at least. >> -- >> Adam Williamson >> Fedora QA Community Monkey >> IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net >> http://www.happyassassin.net >> _______________________________________________ >> devel mailing list -- devel@lists.fedoraproject.org >> To unsubscribe send an email to devel-le...@lists.fedoraproject.org >> Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html >> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines >> List Archives: https://lists.fedoraproject.or >> g/archives/list/devel@lists.fedoraproject.org/message/PCKI2J >> Z54TWHRMFTQAIQP333K5W7MPUQ/ >> > >
_______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/42DQN4CH3SPLTIZV36GPZJQHT66YWQ47/
