On 22.03.21 22:56, Theodore Ts'o wrote: > On Mon, Mar 22, 2021 at 08:25:15PM +0100, Thorsten Leemhuis wrote: >> I agree to the last point and yeah, maybe regressions are the more >> important problem we should work on – at least from the perspective of >> kernel development. But from the users perspective (and >> reporting-issues.rst is written for that perspective) it feel a bit >> unsatisfying to not have a solution to query for existing report, >> regressions or not. Hmmmm... > First of all, thanks for working on reporting-issues.rst. Thx, very glad to hear that. I didn't get much feedback on it, which made me wonder if anybody besides docs folks actually looked at it... > If we can > actually get users to *read* it, I think it's going to save kernel > developers a huge amount of time and frustration. And users hopefully as well. But yes, making them read it is the problem. :-/ > I wonder if it might be useful to have a form which users could be > encouraged to fill out so that (a) the information is available in a > structured format so it's easier for developers to find the relevant > information, (b) so it is easier for programs to parse, for easier > reporting or indexing, and (c) as a nudge so that users remember to > report critical bits of information such as the hardware > configuration, the exact kernel version, which distribution userspace > was in use, etc. > > There could also be something in the text form which would make it > easier for lore.kernel.org searches to identify bug reports. (e.g., > "LINUX KERNEL BUG REPORTER TEMPLATE") Hmmm, yeah, I like that idea. I'll keep it in mind for later: I would prefer to get reporting-issues.rst officially blessed and reporting-bugs.rst gone before working on further enhancements. Maybe the best idea would be to have a script and/or webpage that helps people creating the proper text form (which they then could simply copy-and-paste into their mailer). I had such a script/webpage in mind already to help with one of the IMHO biggest pain points when it comes to reporting issues: finding where the report needs to go, as decoding MAINTAINERS requires that you have a at least a vague idea which component might be causing the issue – which afaics is hard even for people that known a thing or two about the kernel. :-/ Ciao, Thorsten
