linux-kernel - Re: [PATCH v3 0/8] docs: consolidate sysfs-block into Documentation/ABI/

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <87k0f7hzuo.fsf@meer.lwn.net>
Date:   Mon, 10 Jan 2022 17:37:19 -0700
From:   Jonathan Corbet <corbet@....net>
To:     Jens Axboe <axboe@...nel.dk>, Eric Biggers <ebiggers@...nel.org>
Cc:     Bart Van Assche <bvanassche@....org>, linux-block@...r.kernel.org,
        linux-doc@...r.kernel.org,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        linux-kernel@...r.kernel.org
Subject: Re: [PATCH v3 0/8] docs: consolidate sysfs-block into
 Documentation/ABI/

Jens Axboe <axboe@...nel.dk> writes:

> On 1/9/22 2:25 PM, Eric Biggers wrote:
>> I think it makes much more sense for subsystems to be responsible for
>> their own documentation; that's why patch 8 in this series adds the
>> block layer documentation to the block layer MAINTAINERS entry.  Do
>> you disagree with that?
>
> I agree, but then we often end up with merge conflicts between the doc
> tree and others. That's why it's usually punted there. As a maintainer,
> any conflicts is a pain in the butt to deal with, something the
> contributor doesn't necessarily see or understand.
>
> If there are no conflicts this time around, I can queue them up.

[Docs maintainer not copied on any of this, but you can't escape :)]

Maintaining docs is a bit of a challenge for the reason Jens mentions:
everybody puts their fingers into it, and the result is lots of merge
conflicts.  For that reason, I'd prefer that big changes go through the
docs tree.  Changes to directories like Documentation/ABI can be
especially prone to conflicts, FWIW.

I also tend to be a bit more attentive to things like the addition of
docs-build warnings than maintainers from other subsystems.

That said, the real goal is to get more and better documentation merged,
and it often does make the most sense for docs changes to go through
other trees.  Forcing the separation of documentation changes from the
code changes they reflect would be kind of silly at best, for example.
So if the block tree is the best path for these changes, then all I can
say is:

  Acked-by: Jonathan Corbet <corbet@....net>

Thanks,

jon