On Fri, May 29, 2020 at 14:32:10 +0000, Suvayu Ali <fatkasuvayu+linux@xxxxxxxxx> 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.)
_______________________________________________ users mailing list -- users@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to users-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/users@xxxxxxxxxxxxxxxxxxxxxxx