On Fri, May 29, 2020 at 14:32:10 +0000,
Suvayu Ali <fatkasuvayu+linux(a)gmail.com> wrote:
What baffles me most, is the nature of the bug. It is the text book
case of a high priority bug, new (budget) hardware, which is becoming
common place very fast, where Fedora isn't bootable, add to that it is
a regression bug. How does a bug with these characteristics not come
within the peripheral vision of the maintainers, specially when the
reporter is eager to do all kinds of troubleshooting and testing!?
Clearly something is wrong with the automation, the question is. how
should that be fixed?
I occasionally submit kernel bug reports. These days one good way to
get your report looked at is to bisect a Linus kernel to find the commit
that triggered the problem. This normally takes me about a week to get
done. I have gotten fixes for bugs that affected old hardware that was in
limited use by other people. It isn't that hard to do, but kernel builds can
take a while and you need to be able to reboot for each test and there can
be limitations on when that can get done.
I run developmental kernels, so I'm likely to see bugs before others.
Getting the problem noticed upstream before a kernel is released seems to
also increase the odds of someone taking interest in it. For issues before
rc1, I just usually note the issue in a Fedora bug so that others can
notice that others are seeing the same thing. But enough of these get
fixed by rc1 that it usually isn't worth it for me to go through the
trouble of bisecting until after rc1 is released. (That will change with
some newer hardware I'm putting together that will build kernels for that
machine in a lot less time.)