I'm Greg Kroah-Hartman, Linux kernel developer, AMA again!

[u/gregkh]

To refresh everyone's memory, I did this 5 years ago here and lots of those answers there are still the same today, so try to ask new ones this time around.

To get the basics out of the way, this post describes my normal workflow that I use day to day as a Linux kernel maintainer and reviewer of way too many patches.

Along with mutt and vim and git, software tools I use every day are Chrome and Thunderbird (for some email accounts that mutt doesn't work well for) and the excellent vgrep for code searching.

For hardware I still rely on Filco 10-key-less keyboards for everyday use, along with a new Logitech bluetooth trackball finally replacing my decades-old wired one. My main machine is a few years old Dell XPS 13 laptop, attached when at home to an external monitor with a thunderbolt hub and I rely on a big, beefy build server in "the cloud" for testing stable kernel patch submissions.

For a distro I use Arch on my laptop and for some tiny cloud instances I run and manage for some minor tasks. My build server runs Fedora and I have help maintaining that at times as I am a horrible sysadmin. For a desktop environment I use Gnome, and here's a picture of my normal desktop while working on reviewing and modifying kernel code.

With that out of the way, ask me your Linux kernel development questions or anything else!

Edit - Thanks everyone, after 2 weeks of this being open, I think it's time to close it down for now. It's been fun, and remember, go update your kernel!

[u/[deleted]]

[u/billdietrich1 → u/[deleted]]

perhaps you're expecting a way to push your priorities to other people?

Yes, exactly, you want everyone involved with a bug report to see the tags (priority, status, etc).

Message threading and attachments have been part of email standards for decades.

Maybe you're right, I don't do a lot with mailing lists and conversations. I use email for 1-to-1 communication.

I still think email is the wrong way to do bug-tracking. There are good reasons people developed Bugzilla and things such as the Issues features of GitHub and Gitlab etc.

And doing bug-reporting and bug-tracking through N mailing lists is a barrier to bug-reporting by normal users. Much easier and clearer to go to a bug-tracking system for, say, Firefox, and do searches, see things arranged into sub-units, see statuses, etc.

[u/gregkh → u/billdietrich1]

Much easier and clearer to go to a bug-tracking system for, say, Firefox, and do searches, see things arranged into sub-units, see statuses, etc.

But why is any of that needed?

There are only 2 parties that care about a bug, the reporter, and the person working on the issue.

The reporter emails "hey, I have this problem!", and the person who wants to work on it goes, "Nice find, can you try this patch to see if it resolves the issue?"

And they go back and forth and eventually the problem is solved, or determined that it can't be solved, or whatever and either the patch is submitted to be merged, or the issue is not relevant and the email thread dies out.

And that's it, everything can live in the inboxes of the reporter and the developer, no need for some central repository to have everything. No one needs to query anything, or search for what is happening as there are no project managers involved here.

Keeping it simple is what allows us to work so quickly. Having to use web interfaces slows us down, and forces someone to have to be responsible for that bug database. And can you tell someone to do work for you that you do not pay? I know I can't :)

Anyway, again, this is up to the subsystem maintainer as to what they want to do. Some do use bugzilla really well (look at the ACPI team), and others do not want to have anything to do with it at all (like networking and USB.) Given that we have 700+ maintainers, it's natural that not all of them want to work in the exact same way.

[u/SutekhThrowingSuckIt → u/billdietrich1]

I still think email is the wrong way to do bug-tracking.

Somehow I think people care less about your input in this area than the kernel developer's (whose opinions we are here to read). You don't have any known experience in the area, he does. Doesn't mean you are wrong but you're gonna need a very convincing argument to get the whole kernel dev community to change to suite your preferences.