Re: Services that shouldn't be started in the first place: Was F29... hide.. grub

["Gerald B. Cox" <gbcox@xxxxxx>]

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 <gbcox@xxxxxx> 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 <adamwill@xxxxxxxxxxxxxxxxx> 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 <gbcox@xxxxxx> wrote:
>
> >
> >
> > On Thu, Jun 21, 2018 at 6:39 AM, Stephen Gallagher <sgallagh@xxxxxxxxxx>
> > 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@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@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@xxxxxxxxdoraproject.org/message/PCKI2JZ54TWHRMFTQAIQP333K5W7MPUQ/

_______________________________________________
devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
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@xxxxxxxxxxxxxxxxxxxxxxx/message/42DQN4CH3SPLTIZV36GPZJQHT66YWQ47/