Jens Axboe <axboe@xxxxxxxxx> 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@xxxxxxx> Thanks, jon