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: <f48e76f7-6b95-4cf0-82af-424119bb2eb4@www.fastmail.com>
Date:   Fri, 10 May 2019 16:45:45 -0400
From:   "Tobin C. Harding" <me@...in.cc>
To:     "Thomas Hellstrom" <thellstrom@...are.com>,
        "Jonathan Corbet" <corbet@....net>
Cc:     "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "minyard@....org" <minyard@....org>,
        "linux-doc@...r.kernel.org" <linux-doc@...r.kernel.org>,
        "Tobin C. Harding" <tobin@...nel.org>
Subject: Re: [PATCH] docs: Move kref.txt to core-api/kref.rst



On Fri, May 10, 2019, at 20:51, Thomas Hellstrom wrote:
> On Fri, 2019-05-10 at 10:17 +1000, Tobin C. Harding wrote:
> > kref.txt is already written using correct ReStructuredText
> > format.  This
> > can be verified as follows
> > 
> > 	make cleandocs
> > 	make htmldocs 2> pre.stderr
> > 	mv Documentation/kref.txt Documentation/core-api/kref.rst
> > 	// Add 'kref' to core-api/index.rst
> > 	make cleandocs
> > 	make htmldocs 2> post.stderr
> > 	diff pre.stderr post.stderr
> > 
> > While doing the file move, fix the column width to be 72 characters
> > wide
> > as it is throughout the document.  This is whitespace only.  kref.txt
> > is
> > so cleanly written its a shame to have these few extra wide
> > paragraphs.
> > 
> > Signed-off-by: Tobin C. Harding <tobin@...nel.org>
> > ---
> > 
> > I'm always hesitant to do docs patches that seem obvious - is there
> > some reason that this was not done previously?
> 
> Speaking for the two kref.txt paragraphs, the width being too large is
> simply an oversight from my side. I wasn't aware of the restriction.

I'm a stickler for the rules, often to peoples dismay :) AFAIK they say 80 characters for code and 72 for documentation is optimal.  I'm yet to understand why 72 was chosen.  Maybe because its the same length as the git commit long message but that doesn't explain where _that_ came from.  I read once that they used 72 characters on punch cards at times because the other 8 characters got mangled for some reason.  Anyways, its kinda anal and I only change it if it looks like doing so is not going to annoy people _too_ much or, like in this instance, if the file is super clean except for a small portion.  The rest of this file seems to use 72 so I thought it was worth the change.

I'm open to being told otherwise.

Hope this is interesting for you,
Tobin.

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ