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] [thread-next>] [day] [month] [year] [list]
Message-ID: <fff11146-f759-2887-5c80-6449dbc16717@kernel.dk>
Date:   Sun, 9 Jan 2022 18:58:59 -0700
From:   Jens Axboe <axboe@...nel.dk>
To:     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/

On 1/9/22 2:25 PM, Eric Biggers wrote:
> On Sun, Jan 09, 2022 at 10:01:11AM -0700, Jens Axboe wrote:
>> On 1/7/22 1:58 PM, Bart Van Assche wrote:
>>> On 1/6/22 13:41, Eric Biggers wrote:
>>>> Jens, any reason you haven't applied this series yet?  It looks like you've been
>>>> applying other patches.  To be clear, I've been expecting that this would go in
>>>> through the block tree, rather than the docs tree.
>>>
>>> We are close to the v5.17 merge window so this is not a good time for a maintainer to
>>> apply a large patch series. If Jens does not reply I propose to repost this patch
>>> series after the v5.17 merge window has closed (three weeks from now?).
>>
>> I'm fine with it, but it should probably just go through the doc tree.
> 
> 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.

-- 
Jens Axboe

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ