Lines Matching full:fix

72    will often be needed anyway to hunt down and fix issues.
174 switch from 5.9.15 to 5.10.5 does not qualify). The developers want to fix such
212    might not get the issue solved in older releases: the fix might be too big
219    the issue in mainline, as its commit message might tell you if the fix is
222    or peer-review possible fixes; then check the discussions if the fix was
262    the fix in the end will get incorporated in all Linux distributions.
282    will often be needed anyway to hunt down and fix issues.*
300 report and, in case it turns out to be an upstream issue, fix it directly
362 important even when a fix is prepared or in its final stages already, as
364 test a proposed fix. Jump to the section 'Duties after the report went out' for
582 Linux developers want to fix badly, as such issues are even more unwanted than
674 That only leaves these options: arrange yourself to live with the issue, fix it
675 yourself, or find a programmer somewhere willing to fix it.
840 take a few days or weeks. Another reason: the fix you hope for might be too
848 it fixed in older version lines, if that's in the cards for the fix in question.
973 can provide a fix.
1054 recognize from the report want went wrong and can fix it; other times they will
1148    changed just to fix your issue.
1287 to fix it, test it, and send it straight for integration in mainline while
1290 with the fix once it gets released.
1393 possible fix, try to test it in timely manner, too. But do it properly and make
1396 proposed patch with a fix was applied, but in fact wasn't. Things like that
1398 notice when the kernel with the fix behaves just as one without it.
1440 react somehow to every issue report, but they are only obliged to fix those
1448 a fix. Such situations can be devastating, but is within the cards when it
1459 or the change that introduced a regression, which often makes developing a fix
1461 bit about programming and might be able to write a fix.
1499 you find any matches, consider joining the discussion, unless the fix is
1558 reverted to fix the issue quickly). Hence consider to do a proper bisection
1577     might not get the issue solved in older releases: the fix might be too big
1588 fix you are hoping for might be one of those that won't be backported to the
1591 patch the fix into your kernels yourself.
1614     the issue in mainline, as its commit message might tell you if the fix is
1617     or peer-review possible fixes; then check the discussions if the fix was
1626  * First try to find the fix in the Git repository that holds the Linux kernel
1633    If you find the fix, look if the commit message near the end contains a
1638    If that's case the developer marked the fix safe for backporting to version
1642  * If the commit doesn't tell you anything or if you can't find the fix, look
1650  * If you see a proposed fix, search for it in the version control system as
1653    * Check the discussions for any indicators the fix might be too risky to get
1655      to live with the issue or switch to the kernel version line where the fix
1658    * If the fix doesn't contain a stable tag and backporting was not discussed,
1683 will make sure of that. They and the other kernel developers will fix a lot of
1692 These programmers most of the time will happily fix problems other people
1695 Then there are situations where such developers really want to fix an issue,
1749    he'll fix it. You are free to do the same in a mostly informal way if you