linux-kernel - Re: [PATCH 00/32] Create an User's manual and improve development-process book

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 for Android: free password hash cracker in your pocket

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

Message-ID: <20161017164342.28d4f0c3@lwn.net>
Date:   Mon, 17 Oct 2016 16:43:42 -0600
From:   Jonathan Corbet <corbet@....net>
To:     Mauro Carvalho Chehab <mchehab@...pensource.com>
Cc:     Linux Doc Mailing List <linux-doc@...r.kernel.org>,
        Mauro Carvalho Chehab <mchehab@...radead.org>,
        LKML <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH 00/32] Create an User's manual and improve
 development-process book

I've only been able to take a quick look at these - I'm buried fairly deep
at the moment.  A few superficial thoughts.

On Mon, 17 Oct 2016 14:55:37 -0200
Mauro Carvalho Chehab <mchehab@...pensource.com> wrote:

> In my opinion, it would be better to move the converted files to be inside
> a Sphinx build directory, but Jon seems reluctant to that, so, this series
> use symlinks, as it is easy to move the files in the future with a very simple
> patch, if we decide to do so.

So I raised this topic in talks at both Kernel Recipes and LinuxCon
Europe, and nobody threw things at me.  I have come to suspect that I'm
worrying a little too much about it; maybe we should go ahead and move
the documents and see who screams.  The work could go into docs-next soon,
and there would be an opportunity to fix things up if all hell breaks
loose at the kernel summit.

Can I make some silly requests?

- Can we move development-process to something shorter, like just
  "process"?  We'll be typing it a lot, and tab completion doesn't work in
  most email clients :)

- I think we should leave pointers behind in the form of one-line "this
  file has moved" messages.  Probably only SubmittingPatches and
  CodingStyle need that treatment, I think.

- The "user manual" is certainly something that has been on my mind as
  well.  We have documentation for completely separate audiences all mixed
  together now, and definitely need to fix that.  But rather than "user",
  can we paint that shed "admin-guide" or something like that?  

Thanks for doing all of this,

jon