#
d254d263 |
|
15-Nov-2023 |
Borislav Petkov (AMD) <bp@alien8.de> |
docs: submitting-patches: improve the base commit explanation After receiving a second patchset this week without knowing which tree it applies on and trying to apply it on the obvious ones and failing, make sure the base tree information which needs to be supplied in the 0th message of the patchset is spelled out more explicitly. Also, make the formulations stronger as this really is a requirement and not only a useful thing anymore. Signed-off-by: "Borislav Petkov (AMD)" <bp@alien8.de> change-id: <unique-series-id> base-commit: <commit-id-or-tag> Reviewed-by: Kees Cook <keescook@chromium.org> Signed-off-by: Jonathan Corbet <corbet@lwn.net> Link: https://lore.kernel.org/r/20231115170330.16626-1-bp@alien8.de
|
#
1fae02e7 |
|
03-Oct-2023 |
Thomas Weißschuh <linux@weissschuh.net> |
docs: submitting-patches: encourage direct notifications to commenters Commenters may not receive new versions of patches via the lists. Without a directed notification to them they might miss those new versions. This is frustrating for the patch developers as they don't receive their earned Reviewed-by. It is also frustrating for the commenters, as they might think their review got ignored or they have to dig up new versions from the archive manually. So encourage patch submitters to make sure that all commenters get notified also when no Reviewed-by was issued yet. Signed-off-by: Thomas Weißschuh <linux@weissschuh.net> Reviewed-by: Christoph Hellwig <hch@lst.de> Acked-by: Alexander Dahl <ada@thorsis.com> Signed-off-by: Jonathan Corbet <corbet@lwn.net> Link: https://lore.kernel.org/r/20231003-docs-cc-reviewer-v2-1-f93fb946e21e@weissschuh.net
|
#
02f99987 |
|
13-Sep-2023 |
Mark Brown <broonie@kernel.org> |
docs: submitting-patches: Suggest a longer expected time for responses While some subsystems do typically have very fast turnaround times on review this is far from standard over the kernel and is likely to set unrealistic expectations for submitters. Tell submitters to expect 2-3 weeks instead, this will cover more of the kernel. Signed-off-by: Mark Brown <broonie@kernel.org> Reviewed-by: Javier Martinez Canillas <javierm@redhat.com> Signed-off-by: Jonathan Corbet <corbet@lwn.net> Link: https://lore.kernel.org/r/20230913-submitting-patches-delay-v1-1-a2d48c5ca205@kernel.org
|
#
329ac9af |
|
11-May-2023 |
Kees Cook <keescook@chromium.org> |
docs: submitting-patches: Discuss interleaved replies Top-posting has been strongly discouraged in Linux development, but this was actually not written anywhere in the common documentation about sending patches and replying to reviews. Add a section about trimming and interleaved replies. Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Kees Cook <keescook@chromium.org> Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Signed-off-by: Jonathan Corbet <corbet@lwn.net> Link: https://lore.kernel.org/r/20230511184131.gonna.399-kees@kernel.org
|
#
0d828200 |
|
03-Apr-2023 |
Matthieu Baerts <matthieu.baerts@tessares.net> |
docs: process: allow Closes tags with links Since v6.3, checkpatch.pl now complains about the use of "Closes:" tags followed by a link [1]. It also complains if a "Reported-by:" tag is followed by a "Closes:" one [2]. As detailed in the first patch, this "Closes:" tag is used for a bit of time, mainly by DRM and MPTCP subsystems. It is used by some bug trackers to automate the closure of issues when a patch is accepted. It is even planned to use this tag with bugzilla.kernel.org [3]. The first patch updates the documentation to explain what is this "Closes:" tag and how/when to use it. The second patch modifies checkpatch.pl to stop complaining about it. The DRM maintainers and their mailing list have been added in Cc as they are probably interested by these two patches as well. [1] https://lore.kernel.org/all/3b036087d80b8c0e07a46a1dbaaf4ad0d018f8d5.1674217480.git.linux@leemhuis.info/ [2] https://lore.kernel.org/all/bb5dfd55ea2026303ab2296f4a6df3da7dd64006.1674217480.git.linux@leemhuis.info/ [3] https://lore.kernel.org/linux-doc/20230315181205.f3av7h6owqzzw64p@meerkat.local/ This patch (of 5): Making sure a bug tracker is up to date is not an easy task. For example, a first version of a patch fixing a tracked issue can be sent a long time after having created the issue. But also, it can take some time to have this patch accepted upstream in its final form. When it is done, someone -- probably not the person who accepted the patch -- has to remember about closing the corresponding issue. This task of closing and tracking the patch can be done automatically by bug trackers like GitLab [1], GitHub [2] and hopefully soon [3] bugzilla.kernel.org when the appropriated tag is used. The two first ones accept multiple tags but it is probably better to pick one. According to commit 76f381bb77a0 ("checkpatch: warn when unknown tags are used for links"), the "Closes" tag seems to have been used in the past by a few people and it is supported by popular bug trackers. Here is how it has been used in the past: $ git log --no-merges --format=email -P --grep='^Closes: http' | \ grep '^Closes: http' | cut -d/ -f3-5 | sort | uniq -c | sort -rn 391 gitlab.freedesktop.org/drm/intel 79 github.com/multipath-tcp/mptcp_net-next 8 gitlab.freedesktop.org/drm/msm 3 gitlab.freedesktop.org/drm/amd 2 gitlab.freedesktop.org/mesa/mesa 1 patchwork.freedesktop.org/series/73320 1 gitlab.freedesktop.org/lima/linux 1 gitlab.freedesktop.org/drm/nouveau 1 github.com/ClangBuiltLinux/linux 1 bugzilla.netfilter.org/show_bug.cgi?id=1579 1 bugzilla.netfilter.org/show_bug.cgi?id=1543 1 bugzilla.netfilter.org/show_bug.cgi?id=1436 1 bugzilla.netfilter.org/show_bug.cgi?id=1427 1 bugs.debian.org/625804 Likely here, the "Closes" tag was only properly used with GitLab and GitHub. We can also see that it has been used quite a few times (and still used recently) and this is then not a "random tag that makes no sense" like it was the case with "BugLink" recently [4]. It has also been misused but that was a long time ago, when it was common to use many different random tags. checkpatch.pl script should then stop complaining about this "Closes" tag. As suggested by Thorsten [5], if this tag is accepted, it should first be described in the documentation. This is what is done here in this patch. To avoid confusion, the "Closes" should be used with any public bug report. No need to check if the underlying bug tracker supports automations. Having this tag with any kind of public bug reports allows bots like regzbot to clearly identify patches fixing a specific bug and avoid false-positives, e.g. patches mentioning it is related to an issue but not fixing it. As suggested by Thorsten [6] again, if we follow the same logic, the "Closes" tag should then be used after a "Reported-by" one. Note that thanks to this "Closes" tag, the mentioned bug trackers can also locate where a patch has been applied in different branches and repositories. If only the "Link" tag is used, the tracking can also be done but the ticket will not be closed and a manual operation will be needed. Also, these bug trackers have some safeguards: the closure is only done if a commit having the "Closes:" tag is applied in a specific branch. It will then not be closed if a random commit having the same tag is published elsewhere. Also in case of closure, a notification is sent to the owners. Link: https://lkml.kernel.org/r/20230314-doc-checkpatch-closes-tag-v4-0-d26d1fa66f9f@tessares.net Link: https://docs.gitlab.com/ee/user/project/issues/managing_issues.html#default-closing-pattern [1] Link: https://docs.github.com/en/get-started/writing-on-github/working-with-advanced-formatting/using-keywords-in-issues-and-pull-requests [2] Link: https://lore.kernel.org/linux-doc/20230315181205.f3av7h6owqzzw64p@meerkat.local/ [3] Link: https://lore.kernel.org/all/CAHk-=wgs38ZrfPvy=nOwVkVzjpM3VFU1zobP37Fwd_h9iAD5JQ@mail.gmail.com/ [4] Link: https://lore.kernel.org/all/688cd6cb-90ab-6834-a6f5-97080e39ca8e@leemhuis.info/ [5] Link: https://lore.kernel.org/linux-doc/2194d19d-f195-1a1e-41fc-7827ae569351@leemhuis.info/ [6] Link: https://github.com/multipath-tcp/mptcp_net-next/issues/373 Link: https://lkml.kernel.org/r/20230314-doc-checkpatch-closes-tag-v4-1-d26d1fa66f9f@tessares.net Signed-off-by: Matthieu Baerts <matthieu.baerts@tessares.net> Suggested-by: Thorsten Leemhuis <linux@leemhuis.info> Acked-by: Konstantin Ryabitsev <konstantin@linuxfoundation.org> Acked-by: Joe Perches <joe@perches.com> Cc: Andy Whitcroft <apw@canonical.com> Cc: Bagas Sanjaya <bagasdotme@gmail.com> Cc: Daniel Vetter <daniel@ffwll.ch> Cc: David Airlie <airlied@gmail.com> Cc: Dwaipayan Ray <dwaipayanray1@gmail.com> Cc: Jonathan Corbet <corbet@lwn.net> Cc: Kai Wasserbäch <kai@dev.carbon-project.org> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Lukas Bulwahn <lukas.bulwahn@gmail.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
|
#
c0d747a5 |
|
13-Apr-2023 |
Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> |
Documentation/process: always CC responsible lists The "Select the recipients for your patch" part about CC-ing mailing lists is a bit vague and might be understood that only some lists should be Cc-ed. That's not what most of the maintainers expect. For given code, associated mailing list must always be CC-ed, because the list is used for reviewing and testing patches. Example are the Devicetree bindings patches, which are tested iff Devicetree mailing list is CC-ed. Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Link: https://lore.kernel.org/r/20230413165501.47442-1-krzysztof.kozlowski@linaro.org Signed-off-by: Jonathan Corbet <corbet@lwn.net>
|
#
44ac5aba |
|
05-Mar-2023 |
Vegard Nossum <vegard.nossum@oracle.com> |
Documentation/security-bugs: move from admin-guide/ to process/ Jiri Kosina, Jonathan Corbet, and Willy Tarreau all expressed a desire to move this document under process/. Create a new section for security issues in the index and group it with embargoed-hardware-issues. I'm doing this at the start of the series to make all the subsequent changes show up in 'git blame'. Existing references were updated using: git grep -l security-bugs ':!Documentation/translations/' | xargs sed -i 's|admin-guide/security-bugs|process/security-bugs|g' git grep -l security-bugs Documentation/translations/ | xargs sed -i 's|Documentation/admin-guide/security-bugs|Documentation/process/security-bugs|g' git grep -l security-bugs Documentation/translations/ | xargs sed -i '/Original:/s|\.\./admin-guide/security-bugs|\.\./process/security-bugs|g' Notably, the page is not moved in the translations (due to my lack of knowledge of these languages), but the translations have been updated to point to the new location of the original document where these references exist. Link: https://lore.kernel.org/all/nycvar.YFH.7.76.2206062326230.10851@cbobk.fhfr.pm/ Suggested-by: Jiri Kosina <jikos@kernel.org> Cc: Alex Shi <alexs@kernel.org> Cc: Yanteng Si <siyanteng@loongson.cn> Cc: Hu Haowen <src.res@email.cn> Cc: Federico Vaga <federico.vaga@vaga.pv.it> Cc: Tsugikazu Shibata <tshibata@ab.jp.nec.com> Cc: Minchan Kim <minchan@kernel.org> Cc: Jeimi Lee <jamee.lee@samsung.com> Cc: Carlos Bilbao <carlos.bilbao@amd.com> Cc: Akira Yokosawa <akiyks@gmail.com> Signed-off-by: Vegard Nossum <vegard.nossum@oracle.com> Acked-by: Carlos Bilbao <carlos.bilbao@amd.com> Reviewed-by: Yanteng Si <siyanteng@loongson.cn> Reviewed-by: Akira Yokosawa <akiyks@gmail.com> Acked-by: Federico Vaga <federico.vaga@vaga.pv.it> Reviewed-by: Bagas Sanjaya <bagasdotme@gmail.com> Link: https://lore.kernel.org/r/20230305220010.20895-2-vegard.nossum@oracle.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
#
42da2c00 |
|
12-Mar-2023 |
Xujun Leng <lengxujun2007@126.com> |
docs: process: typo fix In the second paragraph of section "Respond to review comments", there is a spelling mistake: "aganst" should be "against". Signed-off-by: Xujun Leng <lengxujun2007@126.com> Link: https://lore.kernel.org/r/20230312071423.3042-1-lengxujun2007@126.com Signed-off-by: Jonathan Corbet <corbet@lwn.net>
|
#
901578a4 |
|
14-Feb-2023 |
Thorsten Leemhuis <linux@leemhuis.info> |
docs: recommend using Link: whenever using Reported-by: Encourage developers to place Link: tag pointing to the report when they are using Reported-by: tags. Those links are often extremely useful for any code archaeologist that wants to know more about the backstory of a change than the commit message provides. That includes maintainers higher up in the patch-flow hierarchy, which is why Linus asks developers to add such links [1, 2, 3]. To quote [1]: > Again, the commit has a link to the patch *submission*, which is > almost entirely useless. There's no link to the actual problem the > patch fixes. > > [...] > > Put another way: I can see that > > Reported-by: Zhangfei Gao <zhangfei.gao@foxmail.com> > > in the commit, but I don't have a clue what the actual report was, and > there really isn't enough information in the commit itself, except for > a fairly handwavy "Device drivers might, for instance, still need to > flush operations.." > > I don't want to know what device drivers _might_ do. I would want to > have an actual pointer to what they do and where. Another reason why these links are wanted: the ongoing regression tracking efforts can only scale with them, as they allow the regression tracking bot 'regzbot' to automatically connect tracked reports with patches that are posted or committed to fix tracked regressions. Link: https://lore.kernel.org/all/CAHk-=wjMmSZzMJ3Xnskdg4+GGz=5p5p+GSYyFBTh0f-DgvdBWg@mail.gmail.com/ [1] Link: https://lore.kernel.org/all/CAHk-=wgs38ZrfPvy=nOwVkVzjpM3VFU1zobP37Fwd_h9iAD5JQ@mail.gmail.com/ [2] Link: https://lore.kernel.org/all/CAHk-=wjxzafG-=J8oT30s7upn4RhBs6TX-uVFZ5rME+L5_DoJA@mail.gmail.com/ [3] Signed-off-by: Thorsten Leemhuis <linux@leemhuis.info> Link: https://lore.kernel.org/r/9a07ec640d809723492f8ade4f54705914e80419.1676369564.git.linux@leemhuis.info Signed-off-by: Jonathan Corbet <corbet@lwn.net>
|
#
d4563201 |
|
26-Feb-2023 |
Linus Torvalds <torvalds@linux-foundation.org> |
Documentation: simplify and clarify DCO contribution example language Long long ago, in a more innocent time, Greg wrote the clarification for how the DCO should work and that you couldn't make anonymous contributions, because the sign-off needed to be something we could check back with. It was 2006, and nobody reacted to the wording, the whole Facebook 'real name' controversy was a decade in the future, and nobody even thought about it. And despite the language, we've always accepted nicknames and that language was never meant to be any kind of exclusionary wording. In fact, even when it became a discussion in other adjacent projects, apparently nobody even thought to just clarify the language in the kernel docs, and instead we had projects like the CNCF that had long discussions about it, and wrote their own clarifications [1] of it. Just simplify the wording to the point where it shouldn't be causing unnecessary angst and pain, or scare away people who go by preferred naming. Link: https://github.com/cncf/foundation/blob/659fd32c86dc/dco-guidelines.md [1] Fixes: af45f32d25cc ("We can not allow anonymous contributions to the kernel") Acked-by: Greg KH <gregkh@linuxfoundation.org> Acked-by: Michael Dolan <mdolan@linuxfoundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
|
#
adb95582 |
|
13-Sep-2022 |
Rong Tao <rtoax@foxmail.com> |
Documentation: process/submitting-patches: misspelling "mesages" Fix spelling mistakes, "mesages" should be spelled "messages". Signed-off-by: Rong Tao <rtoax@foxmail.com> Link: https://lore.kernel.org/r/tencent_924BF0B25425E2D5673409D1CF604F682505@qq.com Signed-off-by: Jonathan Corbet <corbet@lwn.net>
|
#
9db370de |
|
04-Jul-2022 |
Lukas Bulwahn <lukas.bulwahn@gmail.com> |
docs: process: remove outdated submitting-drivers.rst Commit 31b24bee3357 ("docs: add a warning to submitting-drivers.rst") in October 2016 already warns "This (...) should maybe just be deleted, but I'm not quite ready to do that yet". Maybe, six years ago, we were not ready but let us remove old content for the better now and structure and maintain less content in the kernel documentation with a better result. Drop this already outdated document and adjust all textual references. Here is an argument why deleting the content will not remove any useful information to the existing kernel documentation, individually broken down for each section. Section "Allocating Device Numbers" refers to https://www.lanana.org/, and then refers to Documentation/admin-guide/devices.rst. However, the devices.rst clearly states: "The version of this document at lanana.org is no longer maintained." Everything needed for submitting drivers is already stated in devices.rst and the reference to https://www.lanana.org/ is outdated, and should be just deleted. Section "Who To Submit Drivers To" is all about Linux 2.0 - 2.6, before the new release version scheme; the mentioned developers are still around, but actually not the first developers to contact anymore. Section "What Criteria Determine Acceptance" has a few bullet points: Licensing and Copyright is well-covered in process/kernel-license.rst. Interfaces, Code, Portability, Clarity state some obvious things about ensuring kernel code quality. Control suggests to add a MAINTAINERS entry, which is already mentioned in 6.Followthrough.rst: "... added yourself to the MAINTAINERS file..." PM support states a bit about implementing and testing power management of a driver, it remains an open question where to place that in the process documents. Driver developers interested in power management will find the corresponding part on power management in the kernel documentation anyway. In section "What Criteria Do Not Determine Acceptance", the points Vendor and Author states something basic consequence of the kernel being an open-source community software development. Probably no need to mention it nowadays. Section "Resources" lists resources that are also mentioned elsewhere more central. - Linux kernel tree and mailing list is mentioned in many places. - https://lwn.net/Kernel/LDD3/ is mentioned in Documentation/process/kernel-docs.rst. - https://lwn.net/ is mentioned in: - Documentation/process/8.Conclusion.rst - Documentation/process/kernel-docs.rst - https://kernelnewbies.org/ is mentioned in: - Documentation/process/8.Conclusion.rst - Documentation/process/kernel-docs.rst - http://www.linux-usb.org/ is mentioned in Documentation/driver-api/usb/usb.rst - https://landley.net/kdocs/ols/2002/ols2002-pages-545-555.pdf is mentioned in Documentation/process/kernel-docs.rst - https://kernelnewbies.org/KernelJanitors is mentioned in Documentation/process/howto.rst - https://git-scm.com/ is mentioned in - Documentation/process/2.Process.rst - Documentation/process/7.AdvancedTopics.rst - Documentation/process/howto.rst Signed-off-by: Lukas Bulwahn <lukas.bulwahn@gmail.com> Link: https://lore.kernel.org/r/20220704122537.3407-7-lukas.bulwahn@gmail.com Signed-off-by: Jonathan Corbet <corbet@lwn.net>
|
#
f1a69399 |
|
27-Apr-2022 |
Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> |
Documentation/process: use scripts/get_maintainer.pl on patches Explain that, when collecting list of people to Cc the patch, scripts/get_maintainer.pl should be used on patches, not on the directories. The behavior is quite different, because with "-f" on a directory, the maintainers of individual files will not be shown. Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Link: https://lore.kernel.org/r/20220427185645.677039-1-krzysztof.kozlowski@linaro.org Signed-off-by: Jonathan Corbet <corbet@lwn.net>
|
#
6d5aa418 |
|
27-Apr-2022 |
Akira Yokosawa <akiyks@gmail.com> |
docs: submitting-patches: Fix crossref to 'The canonical patch format' The reference to `explicit_in_reply_to` is pointless as when the reference was added in the form of "#15" [1], Section 15) was "The canonical patch format". The reference of "#15" had not been properly updated in a couple of reorganizations during the plain-text SubmittingPatches era. Fix it by using `the_canonical_patch_format`. [1]: 2ae19acaa50a ("Documentation: Add "how to write a good patch summary" to SubmittingPatches") Signed-off-by: Akira Yokosawa <akiyks@gmail.com> Fixes: 5903019b2a5e ("Documentation/SubmittingPatches: convert it to ReST markup") Fixes: 9b2c76777acc ("Documentation/SubmittingPatches: enrich the Sphinx output") Cc: Jonathan Corbet <corbet@lwn.net> Cc: Mauro Carvalho Chehab <mchehab@kernel.org> Cc: stable@vger.kernel.org # v4.9+ Link: https://lore.kernel.org/r/64e105a5-50be-23f2-6cae-903a2ea98e18@gmail.com Signed-off-by: Jonathan Corbet <corbet@lwn.net>
|
#
0c603a5c |
|
01-Apr-2022 |
Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> |
Documentation/process: mention patch changelog in review process Extend the "Respond to review comments" section of "Submitting patches" with reference to patch changelogs. Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Signed-off-by: Jonathan Corbet <corbet@lwn.net>
|
#
869f496e |
|
27-Jan-2022 |
Andy Shevchenko <andriy.shevchenko@linux.intel.com> |
docs: process: submitting-patches: Clarify the Reported-by usage It's unclear from "Submitting Patches" documentation that Reported-by is not supposed to be used against new features. (It's more clear in the section 5.4 "Patch formatting and changelogs" of the "A guide to the Kernel Development Process", where it suggests that change should fix something existing in the kernel. Clarify the Reported-by usage in the "Submitting Patches". Reported-by: Florian Eckert <fe@dev.tdt.de> Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Acked-by: Randy Dunlap <rdunlap@infradead.org> Link: https://lore.kernel.org/r/20220127163258.48482-1-andriy.shevchenko@linux.intel.com Signed-off-by: Jonathan Corbet <corbet@lwn.net>
|
#
081c8919 |
|
10-Jan-2022 |
Jiri Kosina <jkosina@suse.cz> |
Documentation: remove trivial tree As has been discussed some time ago on ksumitt-discuss@ mailinglist, the need for trivial tree diminished over time as all the tooling and processess became much more mature and it's quite natural these days for trivial patches to flow through subsystem trees anyway, so the spin-off of a trivial tree doesn't make sense any more, and is not worth the merge conflicts it might sometimes create. So remove any mentions of it from kernel documentation for good. Link: https://lore.kernel.org/all/nycvar.YFH.7.76.2104222334290.18270@cbobk.fhfr.pm/ Signed-off-by: Jiri Kosina <jkosina@suse.cz>
|
#
6c5ccd24 |
|
14-Dec-2021 |
Miguel Ojeda <ojeda@kernel.org> |
Remove mentions of the Trivial Patch Monkey Apparently, it was decided that trivial@kernel.org is no longer used. Link: https://lore.kernel.org/lkml/fe86efbd-4e03-76c8-55cf-dabd33e85823@infradead.org/ Co-developed-by: Joe Perches <joe@perches.com> Signed-off-by: Joe Perches <joe@perches.com> Signed-off-by: Miguel Ojeda <ojeda@kernel.org> Acked-by: Randy Dunlap <rdunlap@infradead.org> Link: https://lore.kernel.org/r/20211214191415.GA19070@kernel.org Signed-off-by: Jonathan Corbet <corbet@lwn.net>
|
#
aa9b5e0d |
|
19-Nov-2021 |
Erik Ekman <erik@kryo.se> |
Documentation/process: fix self reference Instead link to the device tree document with the same name. Signed-off-by: Erik Ekman <erik@kryo.se> Link: https://lore.kernel.org/r/20211119200758.642474-1-erik@kryo.se Signed-off-by: Jonathan Corbet <corbet@lwn.net>
|
#
b96ff02a |
|
15-Nov-2021 |
Mauro Carvalho Chehab <mchehab+huawei@kernel.org> |
Documentation/process: fix a cross reference The cross-reference for the handbooks section works. However, it is meant to describe the path inside the Kernel's doc where the section is, but there's an space instead of a dash, plus it lacks the .rst at the end, which makes: ./scripts/documentation-file-ref-check to complain. Fixes: 604370e106cc ("Documentation/process: Add maintainer handbooks section") Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org> Signed-off-by: Jonathan Corbet <corbet@lwn.net>
|
#
1f57bd42 |
|
25-Oct-2021 |
Thorsten Leemhuis <linux@leemhuis.info> |
docs: submitting-patches: make section about the Link: tag more explicit Mention the 'Link' tag in the section about adding URLs to the commit msg, to make it clearer they "_primarily_ [...] should be about background", as Linus recently stated (see the link below). That makes the explanation also easier to find with a text search. For the same reason and to improve comprehensibility provide an example, too. Slightly improve the text at the same time to make it more obvious developers are meant to add links to issue reports in mailing list archives, as those allow regression tracking efforts to automatically check which bugs got resolved. Move the section also downwards slightly, to reduce jumping back and forth between aspects relevant for the top and the bottom part of the commit msg. Link: https://lore.kernel.org/lkml/CAHk-=wgBhyLhQLPem1vybKNt7BKP+=qF=veBgc7VirZaXn4FUw@mail.gmail.com/ CC: Konstantin Ryabitsev <konstantin@linuxfoundation.org> Signed-off-by: Thorsten Leemhuis <linux@leemhuis.info> Reviewed-by: Konstantin Ryabitsev <konstantin@linuxfoundation.org> Link: https://lore.kernel.org/r/27105768dc19b395e7c8e7a80d056d1ff9c570d0.1635152553.git.linux@leemhuis.info [jc: tweaked wording following Konstantin's recommendation] Signed-off-by: Jonathan Corbet <corbet@lwn.net>
|
#
a9d85efb |
|
07-Oct-2021 |
Thorsten Leemhuis <linux@leemhuis.info> |
docs: use the lore redirector everywhere Change all links from using the lkml redirector to the lore redirector, as the kernel.org admin recently indicated: we shouldn't be using lkml.kernel.org anymore because the domain can create confusion, as it indicates it is only valid for messages sent to the LKML; the convention has been to use https://lore.kernel.org/r/msgid for this reason. In this process also change three links from using http to https. Link: https://lore.kernel.org/r/20211006170025.qw3glxvocczfuhar@meerkat.local CC: Thomas Gleixner <tglx@linutronix.de> CC: Ingo Molnar <mingo@redhat.com> CC: Borislav Petkov <bp@alien8.de> CC: Hu Haowen <src.res@email.cn> CC: Alex Shi <alexs@kernel.org> CC: Federico Vaga <federico.vaga@vaga.pv.it> Signed-off-by: Thorsten Leemhuis <linux@leemhuis.info> Reviewed-by: Konstantin Ryabitsev <konstantin@linuxfoundation.org> Link: https://lore.kernel.org/r/5bb55bac6ba10fafab19bf2b21572dd0e2f8cea2.1633593385.git.linux@leemhuis.info Signed-off-by: Jonathan Corbet <corbet@lwn.net>
|
#
31c9d7c8 |
|
13-Sep-2021 |
Thomas Gleixner <tglx@linutronix.de> |
Documentation/process: Add tip tree handbook Add a document to the subsystem/maintainer handbook section, which explains what the tip tree is, how it operates and what rules and expectations it has. [ bp: - Add a SPDX identifier, work in most comments from the thread. - 9bf19b78a203 ("Documentation/submitting-patches: Document the SoB chain") is also in the main Documentation but I'm leaving the paragraph here because it has the proper structure - text talks about SoBs and referencing somewhere else would interrupt the flow. - Move backtraces in changelogs to main submitting-patches.rst. - "Patch version information" is explained to a great detail in submitting-patches.rst too. - Hyperlink resend reminders section. ] Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Signed-off-by: Borislav Petkov <bp@suse.de> Reviewed-by: Paul E. McKenney <paulmck@linux.ibm.com> Link: https://lkml.kernel.org/r/20181107171149.165693799@linutronix.de Link: https://lore.kernel.org/r/20210913153942.15251-3-bp@alien8.de Signed-off-by: Jonathan Corbet <corbet@lwn.net>
|
#
604370e1 |
|
13-Sep-2021 |
Thomas Gleixner <tglx@linutronix.de> |
Documentation/process: Add maintainer handbooks section General rules for patch submission, coding style and related details are available, but most subsystems have their subsystem-specific extra rules which differ or go beyond the common rules. Mark suggested to add a subsystem/maintainer handbook section, where subsystem maintainers can explain their specific quirks. Add the section and link to it from the submitting-patches document. [ bp: Add a SPDX identifier. ] Suggested-by: Mark Brown <broonie@kernel.org> Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Signed-off-by: Borislav Petkov <bp@suse.de> Link: https://lkml.kernel.org/r/20181107171149.074948887@linutronix.de Link: https://lore.kernel.org/r/20210913153942.15251-2-bp@alien8.de Signed-off-by: Jonathan Corbet <corbet@lwn.net>
|
#
77167b96 |
|
07-Jul-2021 |
Hannu Hartikainen <hannu@hrtk.in> |
docs: submitting-patches: clarify the role of LKML The documentation previously stated that LKML should be used as *last resort*. However, scripts/get_maintainer.pl always suggests it and in a discussion about changing that[0] it turned out that LKML should in fact receive all patches. Update documentation to make it clear that all patches should be sent to LKML by default, in addition to any subsystem-specific lists. [0]: https://lore.kernel.org/lkml/19a701a8d5837088aa7d8ba594c228c0e040e747.camel@perches.com/ Signed-off-by: Hannu Hartikainen <hannu@hrtk.in> Link: https://lore.kernel.org/r/20210707133634.286840-1-hannu@hrtk.in Signed-off-by: Jonathan Corbet <corbet@lwn.net>
|
#
9912d0bb |
|
16-Jun-2021 |
Mauro Carvalho Chehab <mchehab+huawei@kernel.org> |
docs: process: submitting-patches.rst: avoid using ReST :doc:`foo` markup The :doc:`foo` tag is auto-generated via automarkup.py. So, use the filename at the sources, instead of :doc:`foo`. Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org> Link: https://lore.kernel.org/r/d172ab629c3e32c8d27ed4b9d2a209933e2a7178.1623824363.git.mchehab+huawei@kernel.org Signed-off-by: Jonathan Corbet <corbet@lwn.net>
|
#
6349469a |
|
13-Apr-2021 |
Borislav Petkov <bp@alien8.de> |
Documentation/submitting-patches: Document RESEND tag on patches Explain when a submitter should tag a patch or a patch series with the "RESEND" tag. This has been partially carved out from a tip subsystem handbook patchset by Thomas Gleixner: https://lkml.kernel.org/r/20181107171010.421878737@linutronix.de and incorporates follow-on comments. Signed-off-by: Borislav Petkov <bp@suse.de> Signed-off-by: Jonathan Corbet <corbet@lwn.net>
|
#
875f82cb |
|
15-Feb-2021 |
Borislav Petkov <bp@suse.de> |
Documentation/submitting-patches: Extend commit message layout description Add more blurb about the level of detail that should be contained in a patch's commit message. Extend and make more explicit what text should be added under the --- line. Extend examples and split into more easily palatable paragraphs. This has been partially carved out from a tip subsystem handbook patchset by Thomas Gleixner: https://lkml.kernel.org/r/20181107171010.421878737@linutronix.de and incorporates follow-on comments. Signed-off-by: Borislav Petkov <bp@suse.de> Reviewed-by: Robert Richter <rrichter@amd.com> Link: https://lore.kernel.org/r/20210215141949.GB21734@zn.tnic [jc: Tweaked "example subjects" wording] Signed-off-by: Jonathan Corbet <corbet@lwn.net>
|
#
dbbe7c96 |
|
02-Mar-2021 |
Jakub Kicinski <kuba@kernel.org> |
docs: networking: drop special stable handling Leave it to Greg. Signed-off-by: Jakub Kicinski <kuba@kernel.org> Signed-off-by: David S. Miller <davem@davemloft.net>
|
#
78f101a1 |
|
22-Dec-2020 |
Borislav Petkov <bp@alien8.de> |
Documentation/submitting-patches: Add blurb about backtraces in commit messages Document that backtraces in commit messages should be trimmed down to the useful information only. This has been carved out from a tip subsystem handbook patchset by Thomas Gleixner: https://lkml.kernel.org/r/20181107171010.421878737@linutronix.de and incorporates follow-on comments. Signed-off-by: Borislav Petkov <bp@suse.de> Signed-off-by: Jonathan Corbet <corbet@lwn.net>
|
#
f0ea149e |
|
13-Jan-2021 |
Lee Jones <lee.jones@linaro.org> |
docs: submitting-patches: Emphasise the requirement to Cc: stable when using Fixes: tag Clear-up any confusion surrounding the Fixes: tag with regards to the need to Cc: the stable mailing list when submitting stable patch candidates. Signed-off-by: Lee Jones <lee.jones@linaro.org> Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Cc: Jonathan Corbet <corbet@lwn.net> Cc: linux-doc@vger.kernel.org Link: https://lore.kernel.org/r/20210113163315.1331064-1-lee.jones@linaro.org Signed-off-by: Jonathan Corbet <corbet@lwn.net>
|
#
05a5f51c |
|
10-Jan-2021 |
Joe Perches <joe@perches.com> |
Documentation: Replace lkml.org links with lore Replace the lkml.org links with lore to better use a single source that's more likely to stay available long-term. Done by bash script: cvt_lkml_to_lore () { tmpfile=$(mktemp ./.cvt_links.XXXXXXX) header=$(echo $1 | sed 's@/lkml/@/lkml/headers/@') wget -qO - $header > $tmpfile if [[ $? == 0 ]] ; then link=$(grep -i '^Message-Id:' $tmpfile | head -1 | \ sed -r -e 's/^\s*Message-Id:\s*<\s*//' -e 's/\s*>\s*$//' -e 's@^@https://lore.kernel.org/r/@') # echo "testlink: $link" if [ -n "$link" ] ; then wget -qO - $link > /dev/null if [[ $? == 0 ]] ; then echo $link fi fi fi rm -f $tmpfile } git grep -P -o "\bhttps?://(?:www.)?lkml.org/lkml[\/\w]+" $@ | while read line ; do echo $line file=$(echo $line | cut -f1 -d':') link=$(echo $line | cut -f2- -d':') newlink=$(cvt_lkml_to_lore $link) if [[ -n "$newlink" ]] ; then sed -i -e "s#\b$link\b#$newlink#" $file fi done Link: https://lore.kernel.org/patchwork/patch/1265849/#1462688 Signed-off-by: Joe Perches <joe@perches.com> Link: https://lore.kernel.org/r/77cdb7f32cfb087955bfc3600b86c40bed5d4104.camel@perches.com Signed-off-by: Jonathan Corbet <corbet@lwn.net>
|
#
9bf19b78 |
|
17-Dec-2020 |
Borislav Petkov <bp@alien8.de> |
Documentation/submitting-patches: Document the SoB chain Document what a chain of Signed-off-by's in a patch commit message should mean, explicitly. This has been carved out from a tip subsystem handbook patchset by Thomas Gleixner: https://lkml.kernel.org/r/20181107171010.421878737@linutronix.de and incorporates follow-on comments. Signed-off-by: Borislav Petkov <bp@suse.de> Link: https://lore.kernel.org/r/20201217183756.GE23634@zn.tnic Signed-off-by: Jonathan Corbet <corbet@lwn.net>
|
#
7e902857 |
|
16-Dec-2020 |
Lee Jones <lee.jones@linaro.org> |
docs: submitting-patches: Trivial - fix grammatical error "it is a used" does not make sense. Should be "it is used". Signed-off-by: Lee Jones <lee.jones@linaro.org> Link: https://lore.kernel.org/r/20201216134654.271508-1-lee.jones@linaro.org Signed-off-by: Jonathan Corbet <corbet@lwn.net>
|
#
7d717887 |
|
10-Nov-2020 |
Aditya Srivastava <yashsri421@gmail.com> |
Documentation: include sign off for reverts Currently, we do not have any documentation on commit reverts regarding the requirement of Signed-off-by tag for it. This may be misleading to the users. Evaluating MISSING_SIGN_OFF checkpatch warnings on v4.13..v5.8 showed that 4 out of 11 cases missing a sign-off are revert commits. Add documentation regarding the same to document the community consensus and let readers know. Signed-off-by: Aditya Srivastava <yashsri421@gmail.com> Link: https://lore.kernel.org/r/20201110174749.32068-1-yashsri421@gmail.com Signed-off-by: Jonathan Corbet <corbet@lwn.net>
|
#
030f066f |
|
13-Oct-2020 |
Krzysztof Kozlowski <krzk@kernel.org> |
docs: submitting-patches: describe preserving review/test tags From time to time, the novice kernel contributors do not add Reviewed-by or Tested-by tags to the next versions of the patches. Mostly because they are unaware that responsibility of adding these tags in next version is on submitter, not maintainer. Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org> Link: https://lore.kernel.org/r/20201013162725.13572-1-krzk@kernel.org Signed-off-by: Jonathan Corbet <corbet@lwn.net>
|
#
5ff4aa70 |
|
09-Sep-2020 |
Mauro Carvalho Chehab <mchehab+huawei@kernel.org> |
docs: submitting-patches: use :doc: for references There are two broken references at submitting-patches.rst: Documentation/process/submitting-patches.rst:240: WARNING: undefined label: security-bugs (if the link has no caption the label must precede a section header) Documentation/process/submitting-patches.rst:336: WARNING: undefined label: documentation/process/email-clients.rst (if the link has no caption the label must precede a section header) Those are due to some recent renames and file moves. It turns that maintaining :ref: is currently harder than using :doc:, as we now have a script to help checking such references. So, replace :ref: to :doc: there, making them to point to the current file name. Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org> Link: https://lore.kernel.org/r/3ba405f579cf35ef2b39dd210d8ad46adc79f0ad.1599660067.git.mchehab+huawei@kernel.org Signed-off-by: Jonathan Corbet <corbet@lwn.net>
|
#
9f364b60 |
|
02-Sep-2020 |
Drew DeVault <sir@cmpwn.com> |
submitting-patches.rst: presume git will be used Git is fairly ubiquitous these days, and the additional information in this documentation for preparing patches without it is not especially relevant anymore and may serve to confuse new contributors. The git request-pull comments were also removed, given that it is not a tool well-suited to novice contributors, nor do maintainers especially appreciate receiving unexpected request-pulls from new contributors. Signed-off-by: Drew DeVault <sir@cmpwn.com> Link: https://lore.kernel.org/r/20200903160545.83185-5-sir@cmpwn.com Signed-off-by: Jonathan Corbet <corbet@lwn.net>
|
#
4ebdf7be |
|
02-Sep-2020 |
Drew DeVault <sir@cmpwn.com> |
Documentation/maintainer: rehome sign-off process The repeated sign-offs necessary when a subsystem maintainer modifies an incoming patch has been moved from submitting-patches.rst to Documentation/maintainer, since the affairs of a subsystem maintainer are not especially relevant to someone reading a guide for how to submit their first patch. Signed-off-by: Drew DeVault <sir@cmpwn.com> Link: https://lore.kernel.org/r/20200903160545.83185-4-sir@cmpwn.com Signed-off-by: Jonathan Corbet <corbet@lwn.net>
|
#
7433ff33 |
|
02-Sep-2020 |
Drew DeVault <sir@cmpwn.com> |
Documentation/process: expand plain-text advice This adds a link to https://useplaintext.email to email-clients.rst, which is a more exhaustive resource on configuring various mail clients for plain text use. submitting-patches.rst is also updated to direct readers to email-clients.rst to equip new contributors with the requisite knowledge to become a good participant on the mailing lists. Signed-off-by: Drew DeVault <sir@cmpwn.com> Reviewed-by: Randy Dunlap <rdunlap@infradead.org> Link: https://lore.kernel.org/r/20200903160545.83185-3-sir@cmpwn.com Signed-off-by: Jonathan Corbet <corbet@lwn.net>
|
#
ef227c39 |
|
02-Sep-2020 |
Drew DeVault <sir@cmpwn.com> |
submitting-patches.rst: remove heading numbering This follows similar changes throughout Documentation; these numbers tend to get outdated and are not especially useful. Signed-off-by: Drew DeVault <sir@cmpwn.com> Link: https://lore.kernel.org/r/20200903160545.83185-2-sir@cmpwn.com Signed-off-by: Jonathan Corbet <corbet@lwn.net>
|
#
eb45fb2f |
|
26-Aug-2020 |
Krzysztof Kozlowski <krzk@kernel.org> |
docs: process: Add cross-link to security-bugs The submitting patches mentions criteria for a fix to be called "security fix". Add a link to document explaining the entire process of handling security bugs. Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org> Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Reviewed-by: Felipe Balbi <balbi@kernel.org> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Kees Cook <keescook@chromium.org> Link: https://lore.kernel.org/r/20200827105319.9734-1-krzk@kernel.org Signed-off-by: Jonathan Corbet <corbet@lwn.net>
|
#
5b5bbb8c |
|
10-Jul-2020 |
Tom Rix <trix@redhat.com> |
docs: process: Add an example for creating a fixes tag To make it a little clearer how to create a fixes tag, add an example based on the preceeding gitconfig setup. Signed-off-by: Tom Rix <trix@redhat.com> Link: https://lore.kernel.org/r/20200710200115.21176-1-trix@redhat.com Signed-off-by: Jonathan Corbet <corbet@lwn.net>
|
#
e7b4311e |
|
21-Jun-2020 |
Alexander A. Klimov <grandmaster@al2klimov.de> |
Replace HTTP links with HTTPS ones: Documentation/process Rationale: Reduces attack surface on kernel devs opening the links for MITM as HTTPS traffic is much harder to manipulate. Deterministic algorithm: For each file: If not .svg: For each line: If doesn't contain `\bxmlns\b`: For each link, `\bhttp://[^# \t\r\n]*(?:\w|/)`: If both the HTTP and HTTPS versions return 200 OK and serve the same content: Replace HTTP with HTTPS. Signed-off-by: Alexander A. Klimov <grandmaster@al2klimov.de> Acked-by: Miguel Ojeda <miguel.ojeda.sandonis@gmail.com> Link: https://lore.kernel.org/r/20200621133630.46435-1-grandmaster@al2klimov.de Signed-off-by: Jonathan Corbet <corbet@lwn.net>
|
#
858e6845 |
|
15-Apr-2020 |
Mauro Carvalho Chehab <mchehab+huawei@kernel.org> |
docs: dt: convert submitting-patches.txt to ReST format - Add a SPDX header; - Adjust document and section titles; - Mark literal blocks as such; - Add it to bindings/index.rst. Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org> Signed-off-by: Rob Herring <robh@kernel.org>
|
#
e8686a40 |
|
30-Oct-2019 |
Konstantin Ryabitsev <konstantin@linuxfoundation.org> |
docs: process: Add base-commit trailer usage One of the recurring complaints from both maintainers and CI system operators is that performing git-am on received patches is difficult without knowing the parent object in the git history on which the patches are based. Without this information, there is a high likelihood that git-am will fail due to conflicts, which is particularly frustrating to CI operators. Git versions starting with v2.9.0 are able to automatically include base-commit information using the --base flag of git-format-patch. Document this usage in process/submitting-patches, and add the rationale for its inclusion, plus instructions for those not using git on where the "base-commit:" trailer should go. Signed-off-by: Konstantin Ryabitsev <konstantin@linuxfoundation.org> Signed-off-by: Jonathan Corbet <corbet@lwn.net>
|
#
5aff7c46 |
|
16-Aug-2019 |
Jacob Huisman <jacobhuisman@kernelthusiast.com> |
docs: process: fix broken link http://linux.yyz.us/patch-format.html seems to be down since approximately September 2018. There is a working archive copy on arhive.org. Replaced the links in documenation + translations. Signed-off-by: Jacob Huisman <jacobhuisman@kernelthusiast.com> Reviewed-by: Federico Vaga <federico.vaga@vaga.pv.it> Signed-off-by: Jonathan Corbet <corbet@lwn.net>
|
#
24a2bb90 |
|
22-Mar-2019 |
Sean Christopherson <seanjc@google.com> |
docs: Clarify the usage and sign-off requirements for Co-developed-by The documentation for Co-developed-by is a bit light on details, e.g. it doesn't explicitly state that: - Multiple Co-developed-by tags are perfectly acceptable - Co-developed-by and Signed-off-by must be paired together - SOB ordering should still follow standard sign-off procedure Lack of explicit direction has resulted in developers taking a variety of approaches, often lacking any intent whatsoever, e.g. scattering SOBs willy-nilly, collecting them all at the end or the beginning, etc... Tweak the wording to make it clear that multiple co-authors are allowed, and document the expectation that standard sign-off procedures are to be followed. The use of "original author" has also led to confusion as many patches don't have just one "original" author, e.g. when multiple developers are involved from the genesis of the patch. Remove all usage of "original" and instead call out that Co-developed-by is simply a way to provide attribution in addition to the From tag, i.e. neither tag is intended to imply anything with regard to who did what. Provide examples to (hopefully) eliminate any ambiguity. Cc: Tobin C. Harding <me@tobin.cc> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: Jani Nikula <jani.nikula@linux.intel.com> Cc: Jorge Ramirez-Ortiz <jorge.ramirez-ortiz@linaro.org> Cc: Jonathan Cameron <jic23@kernel.org> Cc: Joe Perches <joe@perches.com> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Cc: Niklas Cassel <niklas.cassel@linaro.org> Cc: Jonathan Corbet <corbet@lwn.net> Signed-off-by: Sean Christopherson <sean.j.christopherson@intel.com> Signed-off-by: Jonathan Corbet <corbet@lwn.net>
|
#
4318f9bb |
|
20-Mar-2019 |
Tom Levy <tomlevy93@gmail.com> |
docs: remove spaces from shell variable assignment The instructions for generating patches are given as shell commands with variables as placeholders. They use the syntax "SRCTREE= linux", which is wrong for the Bourne shell family (it runs the command "linux" with the variable "SRCTREE" set to the empty string). Remove the spaces to avoid confusion. This breaks the pretty alignment but helps new contributors who try to run the commands as written. Signed-off-by: Tom Levy <tomlevy93@gmail.com> Cc: Jonathan Corbet <corbet@lwn.net> Signed-off-by: Jonathan Corbet <corbet@lwn.net>
|
#
19c3fe28 |
|
19-Feb-2019 |
Sean Christopherson <seanjc@google.com> |
docs: Explicitly state that the 'Fixes:' tag shouldn't split lines ...and use a commit with an obnoxiously long summary in the example to make it abundantly clear that keeping the tag on a single line takes priority over wrapping at 75 columns. Without the explicit exemption, one might assume splitting the tag is acceptable, even encouraged, e.g. due to being conditioned by checkpatch's line length warning. Per Stephen's scripts[1] and implied by commit bf4daf12a9fb ("checkpatch: avoid some commit message long line warnings"), splitting the 'Fixes:' tag across multiple lines is a no-no, presumably because parsing multi- line tags is unnecessarily painful. [1] https://lkml.kernel.org/r/20190216183433.71b7cfa7@canb.auug.org.au Cc: Stephen Rothwell <sfr@canb.auug.org.au> Signed-off-by: Sean Christopherson <sean.j.christopherson@intel.com> Signed-off-by: Jonathan Corbet <corbet@lwn.net>
|
#
ae67ee6c |
|
03-Jan-2019 |
Jorge Ramirez-Ortiz <jorge.ramirez-ortiz@linaro.org> |
docs: fix Co-Developed-by docs The accepted terminology will be Co-developed-by therefore lose the capital letter from now on. Link: http://lkml.kernel.org/r/1544808928-20002-2-git-send-email-jorge.ramirez-ortiz@linaro.org Signed-off-by: Jorge Ramirez-Ortiz <jorge.ramirez-ortiz@linaro.org> Acked-by: Himanshu Jha <himanshujha199640@gmail.com> Cc: Jonathan Cameron <jic23@kernel.org> Cc: Joe Perches <joe@perches.com> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Cc: Niklas Cassel <niklas.cassel@linaro.org> Cc: Jonathan Corbet <corbet@lwn.net> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
|
#
f58252cd |
|
25-Jul-2018 |
Tobin C. Harding <me@tobin.cc> |
docs: Add rest label the_canonical_patch_format In preparation to convert Documentation/network/netdev-FAQ.rst to restructured text format. We would like to be able to reference 'the canonical patch format' section. Add rest label: 'the_canonical_patch_format'. Signed-off-by: Tobin C. Harding <me@tobin.cc> Signed-off-by: David S. Miller <davem@davemloft.net>
|
#
3b443955 |
|
06-Apr-2018 |
Matthew Wilcox <willy@infradead.org> |
Docs: tell maintainers to put [GIT PULL] in their subject lines It seems that Linus looks for [GIT PULL] in subject lines to ensure that pull requests don't get buried in the noise during merge windows. Update the docs to reflect that. [jc: From an impromptu post from willy, thus no SOB] Signed-off-by: Jonathan Corbet <corbet@lwn.net>
|
#
82d95343 |
|
04-Mar-2018 |
Tobin C. Harding <me@tobin.cc> |
docs: add Co-Developed-by docs When Co-Developed-by tag was added, docs were only added to Documention/process/5.Posting.rst and were not added to Documention/process/submitting-patches.rst Add documentation to Documention/process/submitting-patches.rst Signed-off-by: Tobin C. Harding <me@tobin.cc> [jc: tweaked commas in the subheading] Signed-off-by: Jonathan Corbet <corbet@lwn.net>
|
#
d19b3e32 |
|
25-Sep-2017 |
Junio C Hamano <gitster@pobox.com> |
Documentation/process: fix the canonical patch format description There shouldn't be a blank line at the beginning, if there is no optional in-body "From" line. There must be a blank line between the body of the explanation and the beginning of the S-o-b lines. Signed-off-by: Junio C Hamano <gitster@pobox.com> Signed-off-by: Jonathan Corbet <corbet@lwn.net>
|
#
bc7938de |
|
20-Jul-2017 |
Frank Rowand <frank.rowand@sony.com> |
docs: submitting-patches - change non-ascii character to ascii Documentation/process/submitting-patches.rst contains a non-ascii character. Change it to the ascii equivalent. Signed-off-by: Frank Rowand <frank.rowand@sony.com> Signed-off-by: Jonathan Corbet <corbet@lwn.net>
|
#
89edeedd |
|
26-Oct-2016 |
Jonathan Corbet <corbet@lwn.net> |
docs: Tweak submitting-patches.rst formatting The main goal here was to get the subsections to show in the TOC as they do for all the other documents. Also call out the DCO in the section title since it's important. Reviewed-by: Mauro Carvalho Chehab <mchehab@s-opensource.com> Signed-off-by: Jonathan Corbet <corbet@lwn.net>
|
#
8c27ceff3 |
|
18-Oct-2016 |
Mauro Carvalho Chehab <mchehab@kernel.org> |
docs: fix locations of several documents that got moved The previous patch renamed several files that are cross-referenced along the Kernel documentation. Adjust the links to point to the right places. Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
|
#
186128f7 |
|
21-Sep-2016 |
Mauro Carvalho Chehab <mchehab@kernel.org> |
docs-rst: add documents to development-process Add several documents to the development-process ReST book. As we don't want renames, use symlinks instead, keeping those documents on their original place. Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
|