linux-kernel - Re: [PULL] Docs for 4.13

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: <CA+55aFxUVMM7HzGccqWk4ByRQAvJ11BN4raL2KL4J7GSXVx-7Q@mail.gmail.com>
Date:   Mon, 3 Jul 2017 21:32:33 -0700
From:   Linus Torvalds <torvalds@...ux-foundation.org>
To:     Jonathan Corbet <corbet@....net>
Cc:     LKML <linux-kernel@...r.kernel.org>,
        "open list:DOCUMENTATION" <linux-doc@...r.kernel.org>
Subject: Re: [PULL] Docs for 4.13

On Mon, Jul 3, 2017 at 6:20 AM, Jonathan Corbet <corbet@....net> 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