Thorsten Leemhuis <linux@xxxxxxxxxxxxx> writes: > Rework the TLDR (aka the short guide) for various reasons: > > * People had to read it entirely and then act upon what they learned, > which from feedback I got was apparently somewhat hard and confusing > given everything we expect from bug reporters; this partly was because > the first paragraph covered a special case (regression in > stable/longterm kernel) and not the main aspect most people cared > about when they came to the document. > > Use a step-by-step approach to avoid this. > > * Make use of > Documentation/admin-guide/verify-bugs-and-bisect-regressions.rst > > * The 'quickly report a stable regression to the stable team' approach > hardly worked out: most of the time the regression was not known yet. > Try a different approach using the regressions list. > > * Reports about stable/longterm regressions most of the time were > greeted with a brief reply along the lines of 'Is mainline affected as > well?'; this is needed to determine who is responsible, so it might as > well make the reporter check that before sending the report (which > verify-bugs-and-bisect-regressions.rst already tells them to do, too). > > Not-signed-off-by: Thorsten Leemhuis <linux@xxxxxxxxxxxxx> > --- > .../admin-guide/reporting-issues.rst | 104 +++++++++++------- > 1 file changed, 62 insertions(+), 42 deletions(-) >From a quick read, no objections here. jon
