diff options
Diffstat (limited to 'Documentation/maintainer')
| -rw-r--r-- | Documentation/maintainer/configure-git.rst | 28 | ||||
| -rw-r--r-- | Documentation/maintainer/maintainer-entry-profile.rst | 2 |
2 files changed, 2 insertions, 28 deletions
diff --git a/Documentation/maintainer/configure-git.rst b/Documentation/maintainer/configure-git.rst index 0a36831814ea..0c21f203cf7a 100644 --- a/Documentation/maintainer/configure-git.rst +++ b/Documentation/maintainer/configure-git.rst @@ -28,31 +28,3 @@ You may also like to tell ``gpg`` which ``tty`` to use (add to your shell rc file):: export GPG_TTY=$(tty) - - -Creating commit links to lore.kernel.org ----------------------------------------- - -The web site https://lore.kernel.org is meant as a grand archive of all mail -list traffic concerning or influencing the kernel development. Storing archives -of patches here is a recommended practice, and when a maintainer applies a -patch to a subsystem tree, it is a good idea to provide a Link: tag with a -reference back to the lore archive so that people that browse the commit -history can find related discussions and rationale behind a certain change. -The link tag will look like this:: - - Link: https://lore.kernel.org/r/<message-id> - -This can be configured to happen automatically any time you issue ``git am`` -by adding the following hook into your git:: - - $ git config am.messageid true - $ cat >.git/hooks/applypatch-msg <<'EOF' - #!/bin/sh - . git-sh-setup - perl -pi -e 's|^Message-I[dD]:\s*<?([^>]+)>?$|Link: https://lore.kernel.org/r/$1|g;' "$1" - test -x "$GIT_DIR/hooks/commit-msg" && - exec "$GIT_DIR/hooks/commit-msg" ${1+"$@"} - : - EOF - $ chmod a+x .git/hooks/applypatch-msg diff --git a/Documentation/maintainer/maintainer-entry-profile.rst b/Documentation/maintainer/maintainer-entry-profile.rst index cda5d691e967..d36dd892a78a 100644 --- a/Documentation/maintainer/maintainer-entry-profile.rst +++ b/Documentation/maintainer/maintainer-entry-profile.rst @@ -59,6 +59,7 @@ week) that patches might be considered for merging and when patches need to wait for the next -rc. At a minimum: - Last -rc for new feature submissions: + New feature submissions targeting the next merge window should have their first posting for consideration before this point. Patches that are submitted after this point should be clear that they are targeting @@ -68,6 +69,7 @@ wait for the next -rc. At a minimum: submissions should appear before -rc5. - Last -rc to merge features: Deadline for merge decisions + Indicate to contributors the point at which an as yet un-applied patch set will need to wait for the NEXT+1 merge window. Of course there is no obligation to ever accept any given patchset, but if the review has not |