Examples of affected pages on docs.kernel.org this patch improves:
  core-api/genalloc.html
  userspace-api/iommufd.html
  userspace-api/liveupdate.html
  core-api/liveupdate.html
  arch/sh/index.html
  arch/x86/sgx.html
  devicetree/kernel-api.html
  userspace-api/fwctl/fwctl-cxl.html
  driver-api/regulator.html
  driver-api/reset.html
  driver-api/s390-drivers.html
  driver-api/scsi.html
  driver-api/spi.html
  driver-api/target.html
  driver-api/wbrf.html
  driver-api/wmi.html

Rito Rhymes (1):
  docs: contain horizontal overflow in C API descriptions

 Documentation/sphinx-static/custom.css | 7 +++++++
 1 file changed, 7 insertions(+)

-- 
2.51.0

Rito Rhymes <rito@ritovision.com> writes:

> Examples of affected pages on docs.kernel.org this patch improves:
>   core-api/genalloc.html
>   userspace-api/iommufd.html
>   userspace-api/liveupdate.html
>   core-api/liveupdate.html
>   arch/sh/index.html
>   arch/x86/sgx.html
>   devicetree/kernel-api.html
>   userspace-api/fwctl/fwctl-cxl.html
>   driver-api/regulator.html
>   driver-api/reset.html
>   driver-api/s390-drivers.html
>   driver-api/scsi.html
>   driver-api/spi.html
>   driver-api/target.html
>   driver-api/wbrf.html
>   driver-api/wmi.html
>
> Rito Rhymes (1):
>   docs: contain horizontal overflow in C API descriptions
>
>  Documentation/sphinx-static/custom.css | 7 +++++++
>  1 file changed, 7 insertions(+)

This is a general comment applying to most of the patches you have sent:
is not a typical or particularly helpful cover letter.  The cover letter
tells reviewers what the series as a whole does; this one does not.
Perhaps more to the point, a cover letter is rarely warranted for a
single patch; just put any relevant information into the changelog of
the patch itself.

In this case, some examples of the problem being solved are certainly
warranted, though perhaps not so many as given here.  They should be in
the patch changelog so that somebody wondering, years from now, why the
patch was applied can gain that understanding.

The names of HTML files are perhaps not ideal; since you're talking
about docs.kernel.org in particular, you could give URLs that people
could view directly.  So, for example:

  https://docs.kernel.org/6.19/core-api/genalloc.html

Note the explicit version so that the problem will be findable in the
distant future, even after the fix is applied.

Thanks,

jon

Thank you for the feedback.

I'll put some examples in the changelogs with versioned URLs and
reroll them without a cover letter.

> The cover letter tells reviewers what the series as a whole does

Admittedly, I knew including a cover letter for a single patch was
non-standard. Given the quantity of examples I aimed to include,
I didn't think it acceptable to include it all in the changelog, but I
knew having the examples was important for testing, so I repurposed the
cover letter as the vehicle for including them. I'll lay off that.

> In this case, some examples of the problem being solved are certainly
> warranted, though perhaps not so many as given here.

I'll scale it down to just a few for the rerolls in the patchlogs.

FWIW my rationale was clear:

"Is this issue a significant enough pattern to justify the risk of
regressions and the review bandwidth required to address it?"

^ I thought it was important to preempt that question given the size
of this repo, assuming layout issues aren't exactly top of mind and
that the potential changes may have systemic effects to consider.

I did an audit for each of the layout fixes and resolved that if I
couldn't find 10 instances of an issue, it would not be worthwhile or
defensible to push. As a first-time contributor here, I figured showing
a concrete list of examples I found was preferable to a take-my-word-
for-it description of each issue's scale while showing only 1 or 2
examples.

> The names of HTML files are perhaps not ideal; since you're
> talking about docs.kernel.org in particular, you could give URLs
> that people could view directly.
> So for example
>
> https://docs.kernel.org/6.19/core-api/genalloc.html
>
> Note the explicit version so that the problem will be findable in the
> distant future, even after the fix is applied.

Yeah that approach makes more sense; the versioning anchors the fix
well for future. I had used neutral HTML file names with local user
testing in mind where the canonical domain wouldn't be used now or in
post-fix source trees.

Rito

"Rito Rhymes" <rito@ritovision.com> writes:

> Thank you for the feedback.
>
> I'll put some examples in the changelogs with versioned URLs and
> reroll them without a cover letter.
>
>> The cover letter tells reviewers what the series as a whole does
>
> Admittedly, I knew including a cover letter for a single patch was
> non-standard. Given the quantity of examples I aimed to include,
> I didn't think it acceptable to include it all in the changelog, but I
> knew having the examples was important for testing, so I repurposed the
> cover letter as the vehicle for including them. I'll lay off that.

If you want to include extra information for reviewers that doesn't
belong in the changelog, you can put it below the "---" line and it will
be stripped out at application time.

Thanks,

jon