Lines Matching +refs:get +refs:reply
98 needs to get reported to the kernel developers separately, unless they are
165 help yourself, if you don't get any help or if it's unsatisfying.
212 might not get the issue solved in older releases: the fix might be too big
213 or risky to get backported there.
262 the fix in the end will get incorporated in all Linux distributions.
323 those often get rejected or ignored, so consider yourself warned. But it's still
325 indirectly will help to get the issue fixed over time.
348 If you get flooded with results consider telling your search engine to limit
365 details on how to get properly involved.
385 fixed as soon as possible, hence there are 'issues of high priority' that get
458 Make sure your kernel doesn't get enhanced
473 they often get set up silently when you install Nvidia's proprietary graphics
476 packages with such software to get rid of any 3rd party kernel module.
553 needs to get reported to the kernel developers separately, unless they are
618 driver. If it's really something else, the driver's developers will get the
789 get rejected or simply ignored.
820 all intrusive ones get merged for the next release during this time. It's a bit
839 needs to be fixed in mainline first before it can get backported, which can
847 further: if the issue doesn't occur with mainline it will guide you how to get
866 are older than a week, as new mainline and stable kernels typically get released
982 might need to get from the Linux sources if your distro does not package it)
1006 Note, if you can't get this to work, simply skip this step and mention the
1008 is, someone might help you to get things going. Also be aware this is just one
1023 promptly reverted if the issue they cause can't get solved quickly any other
1025 get something quickly fixed. But for that to happen the change that's causing
1094 Developers often get quite a lot of mail. They thus often just take a few
1129 * the kernel's messages that you get from ``dmesg`` written to a file. Make
1204 Now that you have the detailed part of the report prepared let's get to the
1210 think this bug affects a lot of users, mention this to get people interested.
1214 get even more abstract and write an even shorter subject/title for the report.
1283 help yourself, if you don't get any help or if it's unsatisfying.*
1289 all you need to do is reply with a 'Thank you very much' and switch to a version
1302 **Always reply in public**: When you filed the issue in a bug tracker, always
1303 reply there and do not contact any of the developers privately about it. For
1306 to your report: go to your mail applications 'Sent' folder and use 'reply-all'
1327 a reply asking for instructions how to do that. But before going that route try
1332 **Be patient**: If you are really lucky you might get a reply to your report
1351 might be appropriate to get a higher authority involved. In case of a WiFi
1354 it's okay to get Linus Torvalds involved.
1359 mail you sent as reply to your report (make sure it has all those in the CC
1367 With all these general things off the table let's get into the details of how
1368 to help to get issues resolved once they were reported.
1381 interacting with. By doing this you also get aware if your report was heard by
1403 Some reports will not get any reaction from the responsible Linux kernel
1411 get the ball running somehow. If the report got out by mail, do that in the
1412 first lines of a mail that is a reply to your initial mail (see above) which
1418 After the reminder wait three more weeks for replies. If you still don't get a
1430 why the report did not get any replies. A good moment for this second reminder
1442 get a reply along the lines of 'thanks for the report, I have more important
1450 getting help are explained in 'Why some issues won't get any reaction or remain
1453 Don't get devastated if you don't find any help or if the issue in the end does
1454 not get solved: the Linux kernel is FLOSS and thus you can still help yourself.
1456 them to get the issue resolved. Such a team could prepare a fresh report
1458 option should get fixed. Maybe together you can also narrow down the root cause
1478 Most kernel version lines only get supported for about three months, as
1486 support for it is likely to be abandoned soon. Then it will get a "end-of-life"
1487 (EOL) stamp. Version lines that reached that point still get mentioned on the
1500 already finished and scheduled to get applied soon.
1539 the start to get the issue reported quickly. Hence a rough description to the
1556 Once your report is out your might get asked to do a proper one, as it allows to
1557 pinpoint the exact change that causes the issue (which then can easily get
1577 might not get the issue solved in older releases: the fix might be too big
1578 or risky to get backported there.*
1585 Complex or risky changes for example do not qualify and thus only get applied
1586 to mainline. Other fixes are easy to get backported to the newest stable and
1622 got fixed there. The commit that fixed it would need to get backported as well
1623 to get the issue solved. That's why you want to search for it or any
1653 * Check the discussions for any indicators the fix might be too risky to get
1671 If the previous three steps didn't get you closer to a solution there is only
1677 Why some issues won't get any reaction or remain unfixed after being reported
1682 to get resolved. The maintainers or if all else fails Linus Torvalds himself
1726 get overwhelmed with reports, even if a driver is working nearly perfectly. To
1727 not get completely stuck, the programmer thus might have no other choice than