David reached out to the maintainers on the relevant ML [0]. Could also CC the regressions@lists.linux.dev [1].
[0] https://lore.kernel.org/linux-input/nycvar.YFH.7.76.23110120... [1] https://www.kernel.org/doc/html/v6.6/admin-guide/reporting-r...
[0] https://lore.kernel.org/linux-input/nycvar.YFH.7.76.23110120... [1] https://www.kernel.org/doc/html/v6.6/admin-guide/reporting-r...
[0] https://www.davidrevoy.com/article995/how-a-kernel-update-br...
Does he not realize how poor of a user experience it is to interact with mailing lists compared to actual bug trackers?
Saying "it's email" means nothing. Just because you announce the name of the tool doesn't make it the right tool.
And what do you mean by unsearchable? There is a search box right there for anyone to use: https://lore.kernel.org/lkml/ Long time subscribers to the list would do a local search from within their own email program, of course.
How do you search for existence bug reports to see if someone else has hit the issue? How do you subscribe to an issue to know if progress is being made on it? How do you keep track of all of the issues. Why is it the user's job to traige bugs to the right person? Microsoft doesn't reccomend you to find the email of someone on the NTFS team if you find a bug in Window's handling of NTFS.
The part about writing and sending the initial is passable using email, but everything else is terrible.
This quite tech-savvy (based on the blog post) user
- Was told how to send the email: https://social.kernel.org/notice/AbN55QfONFCPweYq7E
- Read and attempted to comply with those instructions: https://framapiaf.org/@davidrevoy/111336814871081424
- Still ended up being told they did it wrong: https://lore.kernel.org/linux-input/ZULw6AcBaD6z2UZA@debian....
Edit: Actually, they might have remembered to CC the mailing list, but since they use Proton Mail it probably sent the email encrypted. Don't send encrypted email to mailing lists.
Ideally, mailing lists would make some effort to keep the plain text content in HTML emails rather than just throw it away. If lynx can render full pages in a console, surely we can degrade HTML down to plain-text without too much effort.
Rejecting people who have not taken the time to setup their email client is tradition, but not very helpful.
It trades unhelpfulness between the new submitter and the existing list members; HTML emails are blocked for a reason.
You track the issue by waiting for replies to your email. With a bug tracking system you would wait for replies to the bug report in exactly the same way.
It is not the user’s _job_ to triage bug reports or direct them to the right person, but it is _helpful_ if they can take a minute to peruse the list of kernel modules and find out who the maintainer of the most relevant module is. By adding that person to the CC list of your email, you ensure that they will notice your email right away.
Microsoft has hired hundreds of people to serve as liaison between customers who pay for tech support and the developers who write the code. There’s no way for you to break through that barrier and talk to an NTFS developer directly because Microsoft prefers it that way. The Linux kernel developers cannot afford and do not desire to have that level of bureaucracy in between them and the world.
Not all bugs are sent to a mailing list. From what I can tell it is reccomended that you email the maintainer directly. You can't search for those direct emails. Also I'm not sure that search even is for the place bugs are reported, nor am I confident that it would do a quality search instead of just grepping emails with no ranking.
>You track the issue by waiting for replies to your email.
If you did not make the initial report there isn't a way to get a notification when there is a reply to it.
>There’s no way for you to break through that barrier and talk to an NTFS developer directly
You can just email them. There is no barrier that prevents your email to them or prevent them from talking to you directly.
>The Linux kernel developers cannot afford
The Linux foundation made >240M in revenue last year. They can afford people to triage bugs.
> If you did not make the initial report there isn't a way to get a notification when there is a reply to it.
Sure there is. Send an email and ask for a status update. Be polite about it, and ask for specific information. If you suspect that the work was done and it was committed, ask whose tree it is in. From there you can follow the commit as it is merged into trees owned by people higher and higher in the community, until Linus himself merges it into the next release.
>> There’s no way for you to break through that barrier and talk to an NTFS developer directly
> You can just email them. There is no barrier that prevents your email to them or prevent them from talking to you directly.
If you know who they are, sure. What are you going to do, go on linkedin and hope you get lucky?
> The Linux foundation made >240M in revenue last year. They can afford people to triage bugs.
The Linux Foundation does not run the development of the Linux kernel. They provide support services (like the kernel.org webpage where you can search the mailing lists), legal services, advertising, conferences, etc. The actual development of the kernel is done by volunteers, many of them paid to work on the kernel by their employer.
If you want bug triage or other support services, you should pay for it. Contact Red Hat or whoever and they’ll get you started.
This sucks compared to something like Github where you can just visit an issue or subscribe to it. People don't want to have to SEND AN EMAIL to see the status of something.
>The Linux Foundation does not run the development of the Linux kernel.
But it does fund some of its development.
>> Sure there is. Send an email and ask for a status update. Be polite about it, and ask for specific information. If you suspect that the work was done and it was committed, ask whose tree it is in. From there you can follow the commit as it is merged into trees owned by people higher and higher in the community, until Linus himself merges it into the next release.
> This sucks compared to something like Github where you can just visit an issue or subscribe to it. People don't want to have to SEND AN EMAIL to see the status of something.
Which do you want? Notifications or to visit a website without bothering anybody? If you want a notification, then send an email or just subscribe to the list. You can have your email program or email server move all the email from the list to a folder, and mark everything not in the thread(s) you care about as read if you want, just so that you don’t have to waste your time looking at the emails you don’t care about. Or you could talk to a person. Is that really such an unthinkable action to take?
If you want to visit a website, then just visit the mailing list’s website (<https://lore.kernel.org/lkml/>). Every thread has a page there, such as <https://lore.kernel.org/linux-input/557f1553-4e85-4988-83e4-...>.
You can also mirror the content of the mailing list in several ways, such as by cloning a git repository or downloading mbox files, or by using an NNTP server. See <https://lore.kernel.org/linux-input/_/text/mirror/> for instructions. Feel free to wire that up to any type of automation you want. Make your pager go off any time anyone mentions your pet bug. Make it dim your lights, turn on the RGB LEDs and the projector, and play “Bad to the Bone” at the loudest possible volume when your bug is fixed. Have fun with it!
>> The Linux Foundation does not run the development of the Linux kernel.
> But it does fund some of its development.
All it does is pay people to work on the kernel, it doesn’t mandate how that is done or what gets done. If you want someone to hold your hand so that you don’t have to subscribe to a mailing list, there are several support companies that will happily take your money. Or if you think a lot of people want a bug tracker so that they don’t ever have to talk to another human being, maybe you should provide that service yourself.
This overly complicated. I consider myself more technical than 99% of people and even I couldn't tell you how to do this. How do you except a normal person to be able to figure this out. Do you think your parents could figure this out if they encountered a kernel bug?
>Or if you think a lot of people want a bug tracker so that they don’t ever have to talk to another human being, maybe you should provide that service yourself.
There are plenty of source forges which offer this. Look at what KDE or freedesktop have done with hosting their own.
You don’t even know how to filter the email you get? That is extremely sad. And yes, my parents do know how to set up their own email filters. On the other hand they would probably call me or one of my brothers if they encountered a kernel bug; free family tech support beats troubleshooting any day of the week :P
> There are plenty of source forges which offer this. Look at what KDE or freedesktop have done with hosting their own.
That’s not what I meant. Most kernel developers have no interest in bug trackers, self–hosted or otherwise. If you think that there are enough people who do, you could act as an intermediary by running one yourself and charging for access.
Which is why you hire other people to do it.
And when you have setup your email client, it beats github issues in time efficiency any day.
Contrast that with the Github or Bugzilla experience: make an account, click "report issue", follow the wizard which asks me to provide all the information I need. I am automatically subscribed, and will receive updates via email.
The whole report-via-email might work for experienced kernel developers, but for a regular user trying to just report a single bug it is way too much of a hassle. If I ever encounter a kernel bug, I would go out of my way to avoid directly reporting it upstream - I'd just file it at my distro and let the maintainer deal with the upstream reporting.
> I'd just file it at my distro and let the maintainer deal with the upstream reporting.
They even ask you to do that _in the instructions_ that you haven’t read due to laziness.
You'd be hard-pressed to call me "lazy", to be honest. I'm more than happy to dig into the kernel source to determine the cause of such a regression because I actually like doing that kind of thing. I've submitted several single-digit-line patches to large projects to solve exactly this kind of issue.
Spending a Saturday morning trying to figure out a kernel bug is quite enjoyable. Spending a Saturday afternoon trying to figure out how to submit a bug report or patch is not - especially when it is literally a 5-minute process for the vast majority of other software projects. If I have to deal with that much bureaucracy, I'll just keep my patch to myself.