workflows.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* [PATCH v2] docs: maintainer: Fix ambiguous subheading formatting
@ 2025-09-16 22:29 Thorsten Blum
  2025-09-16 23:28 ` Randy Dunlap
                   ` (2 more replies)
  0 siblings, 3 replies; 4+ messages in thread
From: Thorsten Blum @ 2025-09-16 22:29 UTC (permalink / raw)
  To: Jonathan Corbet
  Cc: Thorsten Blum, Randy Dunlap, workflows, linux-doc, linux-kernel

Add a newline after both subheadings to avoid any ambiguous formatting,
especially in htmldocs. Without the newline, subheadings are rendered as
part of the following paragraphs, which can be confusing to read.

Suggested-by: Randy Dunlap <rdunlap@infradead.org>
Signed-off-by: Thorsten Blum <thorsten.blum@linux.dev>
---
Changes in v2:
- Fix subheading formatting with newlines as suggested by Randy
- Link to v1: https://lore.kernel.org/r/20250915192235.2414746-2-thorsten.blum@linux.dev/
---
 Documentation/maintainer/maintainer-entry-profile.rst | 2 ++
 1 file changed, 2 insertions(+)

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
-- 
2.51.0


^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: [PATCH v2] docs: maintainer: Fix ambiguous subheading formatting
  2025-09-16 22:29 [PATCH v2] docs: maintainer: Fix ambiguous subheading formatting Thorsten Blum
@ 2025-09-16 23:28 ` Randy Dunlap
  2025-09-17 10:20 ` Bagas Sanjaya
  2025-09-18 16:28 ` Jonathan Corbet
  2 siblings, 0 replies; 4+ messages in thread
From: Randy Dunlap @ 2025-09-16 23:28 UTC (permalink / raw)
  To: Thorsten Blum, Jonathan Corbet; +Cc: workflows, linux-doc, linux-kernel



On 9/16/25 3:29 PM, Thorsten Blum wrote:
> Add a newline after both subheadings to avoid any ambiguous formatting,
> especially in htmldocs. Without the newline, subheadings are rendered as
> part of the following paragraphs, which can be confusing to read.
> 
> Suggested-by: Randy Dunlap <rdunlap@infradead.org>
> Signed-off-by: Thorsten Blum <thorsten.blum@linux.dev>

Reviewed-by: Randy Dunlap <rdunlap@infradead.org>
Tested-by: Randy Dunlap <rdunlap@infradead.org>

Thanks.

> ---
> Changes in v2:
> - Fix subheading formatting with newlines as suggested by Randy
> - Link to v1: https://lore.kernel.org/r/20250915192235.2414746-2-thorsten.blum@linux.dev/
> ---
>  Documentation/maintainer/maintainer-entry-profile.rst | 2 ++
>  1 file changed, 2 insertions(+)
> 
> 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

-- 
~Randy

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: [PATCH v2] docs: maintainer: Fix ambiguous subheading formatting
  2025-09-16 22:29 [PATCH v2] docs: maintainer: Fix ambiguous subheading formatting Thorsten Blum
  2025-09-16 23:28 ` Randy Dunlap
@ 2025-09-17 10:20 ` Bagas Sanjaya
  2025-09-18 16:28 ` Jonathan Corbet
  2 siblings, 0 replies; 4+ messages in thread
From: Bagas Sanjaya @ 2025-09-17 10:20 UTC (permalink / raw)
  To: Thorsten Blum, Jonathan Corbet
  Cc: Randy Dunlap, workflows, linux-doc, linux-kernel

[-- Attachment #1: Type: text/plain, Size: 1320 bytes --]

On Wed, Sep 17, 2025 at 12:29:44AM +0200, Thorsten Blum wrote:
> 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

LGTM, thanks!

Reviewed-by: Bagas Sanjaya <bagasdotme@gmail.com>

-- 
An old man doll... just what I always wanted! - Clara

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: [PATCH v2] docs: maintainer: Fix ambiguous subheading formatting
  2025-09-16 22:29 [PATCH v2] docs: maintainer: Fix ambiguous subheading formatting Thorsten Blum
  2025-09-16 23:28 ` Randy Dunlap
  2025-09-17 10:20 ` Bagas Sanjaya
@ 2025-09-18 16:28 ` Jonathan Corbet
  2 siblings, 0 replies; 4+ messages in thread
From: Jonathan Corbet @ 2025-09-18 16:28 UTC (permalink / raw)
  To: Thorsten Blum
  Cc: Thorsten Blum, Randy Dunlap, workflows, linux-doc, linux-kernel

Thorsten Blum <thorsten.blum@linux.dev> writes:

> Add a newline after both subheadings to avoid any ambiguous formatting,
> especially in htmldocs. Without the newline, subheadings are rendered as
> part of the following paragraphs, which can be confusing to read.
>
> Suggested-by: Randy Dunlap <rdunlap@infradead.org>
> Signed-off-by: Thorsten Blum <thorsten.blum@linux.dev>
> ---
> Changes in v2:
> - Fix subheading formatting with newlines as suggested by Randy
> - Link to v1: https://lore.kernel.org/r/20250915192235.2414746-2-thorsten.blum@linux.dev/
> ---
>  Documentation/maintainer/maintainer-entry-profile.rst | 2 ++
>  1 file changed, 2 insertions(+)

Applied, thanks.

jon

^ permalink raw reply	[flat|nested] 4+ messages in thread

end of thread, other threads:[~2025-09-18 16:28 UTC | newest]

Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2025-09-16 22:29 [PATCH v2] docs: maintainer: Fix ambiguous subheading formatting Thorsten Blum
2025-09-16 23:28 ` Randy Dunlap
2025-09-17 10:20 ` Bagas Sanjaya
2025-09-18 16:28 ` Jonathan Corbet

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox