Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751954AbdGDEcg (ORCPT ); Tue, 4 Jul 2017 00:32:36 -0400 Received: from mail-oi0-f48.google.com ([209.85.218.48]:34122 "EHLO mail-oi0-f48.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750792AbdGDEce (ORCPT ); Tue, 4 Jul 2017 00:32:34 -0400 MIME-Version: 1.0 In-Reply-To: <20170703072040.7ccde29b@lwn.net> References: <20170703072040.7ccde29b@lwn.net> From: Linus Torvalds Date: Mon, 3 Jul 2017 21:32:33 -0700 X-Google-Sender-Auth: IQolMJCBvb-uBSedilIPJwi2x7U Message-ID: Subject: Re: [PULL] Docs for 4.13 To: Jonathan Corbet Cc: LKML , "open list:DOCUMENTATION" Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1838 Lines: 43 On Mon, Jul 3, 2017 at 6:20 AM, Jonathan Corbet wrote: > You'll also encounter more than the usual number of conflicts, which > is saying something. Hmm. I fixed the ones that were actual data conflicts, but I think there ends up being several things that are just stale or didn't get updated by other pulls. Eg things like Error: Cannot open file ./kernel/rcu/srcu.c Error: Cannot open file ./kernel/rcu/srcu.c happen simply because that file no longer exists, and the docs never got updated. So my merge didn't even try to fix those kinds of things at all. I literally just looked at the conflicts and moved those over to the rst files, and that was it. There's a lot of other changes that never cause conflicts for the simple reason that those changes never caused documentation changes to begin with. Now, this is obviously not new, but it does strike me that if checking for these kinds of things was easier and part of "make allmodconfig", then we might have less of it happen. At the same time, lots of people run a lot of builds, and while I'd love to see warnings about docs failures, I am *not* willing to slow down my usual build enormously. I run "male allmodconfig" builds between every single pull during the merge window, and while it's often parallel with me looking at the problems, I don't really want to slow the build down too much. And the doc building is still *slow*. Is there some fast "just basic sanity checks" that would be more reasonable? Because one thing that the switch to sphinx has done is that the doc build environment seems saner (tool-wise). So now that kind of thing would at least be _possible_ to do in ways I don't think was reasonable with docbook. And now docbook is finally gone. But sphinx isn't exactly a speed demon either. Linus