Bagas Sanjaya <bagasdotme@xxxxxxxxx> writes: > The patch submission guidelines in MAINTAINERS are redundant, since > submitting-patches does the job and more up-to-date to current kernel > development process. > > Remove the guidelines, while also move trivial patch suggestion to > submitting-patches. > > Signed-off-by: Bagas Sanjaya <bagasdotme@xxxxxxxxx> > --- > Documentation/process/submitting-patches.rst | 4 +- > MAINTAINERS | 78 +------------------- > 2 files changed, 6 insertions(+), 76 deletions(-) So I'm generally in favor of this change, but ... > diff --git a/Documentation/process/submitting-patches.rst b/Documentation/process/submitting-patches.rst > index a1cb6280fbcf4e..bb720c057de7d7 100644 > --- a/Documentation/process/submitting-patches.rst > +++ b/Documentation/process/submitting-patches.rst > @@ -15,7 +15,9 @@ Documentation/process/submit-checklist.rst > for a list of items to check before submitting code. If you are submitting > a driver, also read Documentation/process/submitting-drivers.rst; for device > tree binding patches, read This won't apply - submitting-drivers.rst is gone. > -Documentation/devicetree/bindings/submitting-patches.rst. > +Documentation/devicetree/bindings/submitting-patches.rst. Not all suggestions > +presented here matter on every patch (including trivial ones), so apply > +some common sense. > > This documentation assumes that you're using ``git`` to prepare your patches. > If you're unfamiliar with ``git``, you would be well-advised to learn how to > diff --git a/MAINTAINERS b/MAINTAINERS > index 64379c699903bc..8d668a0ec903e4 100644 > --- a/MAINTAINERS > +++ b/MAINTAINERS > @@ -1,81 +1,9 @@ > List of maintainers and how to submit kernel changes > ==================================================== > > -Please try to follow the guidelines below. This will make things > -easier on the maintainers. Not all of these guidelines matter for every > -trivial patch so apply some common sense. > - > -Tips for patch submitters > -------------------------- > - > -1. Always *test* your changes, however small, on at least 4 or > - 5 people, preferably many more. > - > -2. Try to release a few ALPHA test versions to the net. Announce > - them onto the kernel channel and await results. This is especially > - important for device drivers, because often that's the only way > - you will find things like the fact version 3 firmware needs > - a magic fix you didn't know about, or some clown changed the > - chips on a board and not its name. (Don't laugh! Look at the > - SMC etherpower for that.) > - > -3. Make sure your changes compile correctly in multiple > - configurations. In particular check that changes work both as a > - module and built into the kernel. > - > -4. When you are happy with a change make it generally available for > - testing and await feedback. > - > -5. Make a patch available to the relevant maintainer in the list. Use > - ``diff -u`` to make the patch easy to merge. Be prepared to get your > - changes sent back with seemingly silly requests about formatting > - and variable names. These aren't as silly as they seem. One > - job the maintainers (and especially Linus) do is to keep things > - looking the same. Sometimes this means that the clever hack in > - your driver to get around a problem actually needs to become a > - generalized kernel feature ready for next time. > - > - PLEASE check your patch with the automated style checker > - (scripts/checkpatch.pl) to catch trivial style violations. > - See Documentation/process/coding-style.rst for guidance here. > - > - PLEASE CC: the maintainers and mailing lists that are generated > - by ``scripts/get_maintainer.pl.`` The results returned by the > - script will be best if you have git installed and are making > - your changes in a branch derived from Linus' latest git tree. > - See Documentation/process/submitting-patches.rst for details. > - > - PLEASE try to include any credit lines you want added with the > - patch. It avoids people being missed off by mistake and makes > - it easier to know who wants adding and who doesn't. > - > - PLEASE document known bugs. If it doesn't work for everything > - or does something very odd once a month document it. > - > - PLEASE remember that submissions must be made under the terms > - of the Linux Foundation certificate of contribution and should > - include a Signed-off-by: line. The current version of this > - "Developer's Certificate of Origin" (DCO) is listed in the file > - Documentation/process/submitting-patches.rst. > - > -6. Make sure you have the right to send any changes you make. If you > - do changes at work you may find your employer owns the patch > - not you. > - > -7. When sending security related changes or reports to a maintainer > - please Cc: security@xxxxxxxxxx, especially if the maintainer > - does not respond. Please keep in mind that the security team is > - a small set of people who can be efficient only when working on > - verified bugs. Please only Cc: this list when you have identified > - that the bug would present a short-term risk to other users if it > - were publicly disclosed. For example, reports of address leaks do > - not represent an immediate threat and are better handled publicly, > - and ideally, should come with a patch proposal. Please do not send > - automated reports to this list either. Such bugs will be handled > - better and faster in the usual public places. See > - Documentation/admin-guide/security-bugs.rst for details. > - > -8. Happy hacking. > +If you'd like to submit kernel changes (patches), refer to > +:ref:`submittingpatches` for the guidelines, and > +:ref:`development_process_main` for detailed guide on development process. Let's not put RST directives into MAINTAINERS, which isn't an RST file. Just mention Documentation/whatever and all will be good. Thanks, jon
