Documentation/admin-guide/reporting-issues.rst

4 Reporting issues
56 reporting issues to Free/Libre & Open Source Software (FLOSS) projects. For
70    document and reporting the issue to your vendor instead, unless you are
117    go and install it for the reporting process. Testing and reporting with
168 Reporting regressions within a stable and longterm kernel line
203 Reporting issues only occurring in older kernel version lines
234 Reference section: Reporting issues to the kernel maintainers
280    document and reporting the issue to your vendor instead, unless you are
294 Most of these vendor kernels are quite unsuitable for reporting issues to the
324 better than not reporting the issue at all: sometimes such reports directly or
336 Reporting an issue that someone else already brought forward is often a waste of
341 to be reported to. Nevertheless, do not hurry with this step of the reporting
386 handled slightly differently in the reporting process. Three type of cases
392 Documentation/admin-guide/reporting-regressions.rst explains this in more
562 Additionally, during the reporting process you will have to test if the issue
740 As mentioned earlier already: reporting an issue that someone else already
766 Do not hurry with this step of the reporting process: spending 30 to 60 minutes
774     go and install it for the reporting process. Testing and reporting with
787 before reporting it. You are free to ignore this advice, but as outlined
817 suspending the reporting process until the first pre-release of the next
833 using it for reproducing the issue is also better than not reporting it issue
841 hard or risky for backporting; reporting the issue again hence is unlikely to
845 are unsuitable for this part of the reporting process: they are to distant from
857 unsuitable for testing and issue reporting: the changes might cause the issue
906 hard to reproduce. Sending an undecoded report is better than not reporting
920 eliminate the reason for it before you reporting issues that occur with it. See
937 head over to the section "Details about reporting issues only occurring in
1024 way. Reporting a regression is thus a bit like playing a kind of trump card to
1051 version which introduced the regression, feel free to move on in the reporting
1063 Documentation/admin-guide/reporting-regressions.rst; that document also
1254 If that's not the case simply proceed with reporting the issue as described.
1255 For issues that bear such a risk you will need to adjust the reporting process
1423 issue reporting and ask for their opinion. Also ask them for their advice how
1464 Reference for "Reporting regressions within a stable and longterm kernel line"
1489 reporting.
1537 When reporting a regression that happens within a stable or longterm kernel
1566 Reference for "Reporting issues only occurring in older kernel version lines"
1596     *Perform the first three steps in the section "Reporting issues only
1680 When reporting a problem to the Linux developers, be aware only 'issues of high
1759 …rg/pub/scm/linux/kernel/git/torvalds/linux.git/plain/Documentation/admin-guide/reporting-issues.rst