public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Mauro Carvalho Chehab <mchehab@s-opensource.com>
To: Jonathan Corbet <corbet@lwn.net>
Cc: Linux Doc Mailing List <linux-doc@vger.kernel.org>,
	Mauro Carvalho Chehab <mchehab@infradead.org>,
	Markus Heiser <markus.heiser@darmarit.de>,
	Jani Nikula <jani.nikula@linux.intel.com>,
	LKML <linux-kernel@vger.kernel.org>, Greg KH <greg@kroah.com>
Subject: Re: [PATCH v4 00/29] Create a book for Kernel development
Date: Wed, 21 Sep 2016 06:20:20 -0300	[thread overview]
Message-ID: <20160921062020.52cb0d32@vento.lan> (raw)
In-Reply-To: <20160920184454.0b5ae2a0@lwn.net>

Em Tue, 20 Sep 2016 18:44:54 -0600
Jonathan Corbet <corbet@lwn.net> escreveu:

> On Mon, 19 Sep 2016 08:07:34 -0300
> Mauro Carvalho Chehab <mchehab@s-opensource.com> wrote:
> 
> > That's the 4th version of this series. It also contains a second patch series
> > with more ReST conversions and documentation improvements.
> > This patchset merges the content of a second patch series:
> > 
> > 	[PATCH 00/17] Improve documentation for the development-process
> >   
> 
> OK, I'm applying these through 28; I'm going to hold off on #29.  Thanks
> for separating that part out so nicely.
> 
> > I opted to keep the patch changing the  kernel-docs.txt changes
> > (patch 21/29). The patch is already written and another patch
> > (patch 22/29)  depends on it, because there are references to
> > this file at Documentation/HOWTO.
> >
> > It shouldn't be hard  to get rid of it, but I'm not sure if worths
> > the effort. As I commented, people might find useful to update
> > it to point to more modern documents. If people won't do it,
> > it can still be removed from the Kernel a the next Kernel version.  
> 
> I'll take them for now, since there seems to be interest in doing something
> with this document.  I kept the applying-patches one as well.  But I do
> think that we need to start being a bit more willing to get rid of musty
> old docs.  We don't carry unused code because "it might be useful to
> somebody"; I think we should take the same approach to docs.  Out-of-date
> or irrelevant docs are a maintenance burden, and they impose a heavy burden
> on the people the docs are most meant to help...
> 
> A few notes:
> 
> #1 didn't apply, I had to do it by hand.  I suspect my late application of
> Marcus's work got in the way there.
> 
> #2 had this:
> 
> > Content-Type: text/plain; charset=true  
> 
> ...which threw git am for a loop; I had to fix it manually.  What gives
> there?

That's really weird! I did only the usual stuff here... patches created
with git format-patch and C/C added via get_maintainers.pl. The
resulting patch is sent via:
	git send-email patches/tmp

I double-checked: the patches created are without any Content-Type:.
It is git send-email (git-2.7.4-2.fc24.x86_64) that added those:

	Content-Type: text/plain; charset=true
	Content-Transfer-Encoding: 8bit

I'll try to investigate what's wrong there or otherwise check if
the upstream version from git's repository works better.

> 
> #4 didn't apply and had to be done by hand.
> 
> #10 (CodingStyle) has a lot of ".. code-block:: c" constructs.  Why are
> those needed?  We're still using C by default for literal blocks, right?

I opted to keep the code-block there, because, at least on one of the
blocks, we had to use:

	.. code-block:: none

Because pygments were doing weird highlights on it. So, for coherency,
I ended by keeping it all along.

> 
> #15 (SecurityBugs) leaves the section numbers in place; did you intend
> that?

Yes. Since we remove the :numbered:, and this document had already
the sections numbered manually, I opted to preserve.

Yet, I don't see anything special there that would justify
numbering. So, I guess we can just remove it.

> #21 (kernel-docs.txt) had the charset=true weirdness
> 
> #28 actually, I balked at applying this one, since it assumes that
>     the great renaming is taking place, and that hasn't happened yet.

Oh! Ok, I'll fix this one, removing the rename stuff from the
conversion and resend.

> So actually I only went through #27, but that took a long time - seemingly
> longer than it takes you to create them! :)

Sorry for that. I'll try to make it easier for you next time.

> A few of the patches still have the bare "::" lines in them; I think I'll
> just add a patch to fix those up real quick.

OK.

Thanks,
Mauro

      reply	other threads:[~2016-09-21  9:20 UTC|newest]

Thread overview: 33+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-09-19 11:07 [PATCH v4 00/29] Create a book for Kernel development Mauro Carvalho Chehab
2016-09-19 11:07 ` [PATCH v4 01/29] doc-rst: add CSS styles for :kbd: and :menuselection: Mauro Carvalho Chehab
2016-09-19 11:07 ` [PATCH v4 02/29] doc: development-process: convert it to ReST markup Mauro Carvalho Chehab
2016-09-19 11:07 ` [PATCH v4 03/29] doc: development-process: rename files to rst Mauro Carvalho Chehab
2016-09-19 11:07 ` [PATCH v4 04/29] docs-rst: create a book for the development process Mauro Carvalho Chehab
2016-09-19 11:07 ` [PATCH v4 05/29] Documentation/HOWTO: convert to ReST notation Mauro Carvalho Chehab
2016-09-19 11:07 ` [PATCH v4 06/29] Documentation/applying-patches.txt: convert it to ReST markup Mauro Carvalho Chehab
2016-09-19 11:07 ` [PATCH v4 07/29] Documentation/applying-patches.txt: Update the information there Mauro Carvalho Chehab
2016-09-19 11:07 ` [PATCH v4 08/29] Documentation/Changes: convert it to ReST markup Mauro Carvalho Chehab
2016-09-19 11:07 ` [PATCH v4 09/29] Documentation/Changes: add minimal requirements for documentation build Mauro Carvalho Chehab
2016-09-19 11:07 ` [PATCH v4 10/29] Documentation/CodingStyle: Convert to ReST markup Mauro Carvalho Chehab
2016-09-19 11:07 ` [PATCH v4 11/29] Documentation/CodingStyle: use the proper tag for verbatim font Mauro Carvalho Chehab
2016-09-19 11:07 ` [PATCH v4 12/29] Documentation/CodingStyle: replace underline markups Mauro Carvalho Chehab
2016-09-19 11:07 ` [PATCH v4 13/29] Documentation/CodingStyle: use the .. note:: markup where needed Mauro Carvalho Chehab
2016-09-19 11:07 ` [PATCH v4 14/29] Documentation/ManagementStyle: convert it to ReST markup Mauro Carvalho Chehab
2016-09-19 11:07 ` [PATCH v4 15/29] Documentation/SecurityBugs: " Mauro Carvalho Chehab
2016-09-19 11:07 ` [PATCH v4 16/29] Documentation/stable_api_nonsense.txt: " Mauro Carvalho Chehab
2016-09-19 11:07 ` [PATCH v4 17/29] Documentation/stable_kernel_rules.txt: " Mauro Carvalho Chehab
2016-09-20  7:08   ` Greg KH
2016-09-19 11:07 ` [PATCH v4 18/29] Documentation/SubmittingDrivers: " Mauro Carvalho Chehab
2016-09-19 11:07 ` [PATCH v4 19/29] Documentation/SubmittingPatches: " Mauro Carvalho Chehab
2016-09-19 11:07 ` [PATCH v4 20/29] Documentation/SubmittingPatches: enrich the Sphinx output Mauro Carvalho Chehab
2016-09-19 11:07 ` [PATCH v4 21/29] Documentation/kernel-docs.txt: convert it to ReST markup Mauro Carvalho Chehab
2016-09-19 11:07 ` [PATCH v4 22/29] Documentation/HOWTO: add cross-references to other documents Mauro Carvalho Chehab
2016-09-20  7:08   ` Greg KH
2016-09-19 11:07 ` [PATCH v4 23/29] Documentation/HOWTO: update information about generating documentation Mauro Carvalho Chehab
2016-09-19 11:07 ` [PATCH v4 24/29] Documentation/HOWTO: improve some markups to make it visually better Mauro Carvalho Chehab
2016-09-19 11:07 ` [PATCH v4 25/29] Documentation/HOWTO: adjust external link references Mauro Carvalho Chehab
2016-09-19 11:08 ` [PATCH v4 26/29] Documentation/SubmitChecklist: update kernel-doc task Mauro Carvalho Chehab
2016-09-19 11:08 ` [PATCH v4 27/29] Documentation/SubmitChecklist: convert it to ReST markup Mauro Carvalho Chehab
2016-09-19 11:08 ` [PATCH v4 28/29] Documentation/email-clients.txt: " Mauro Carvalho Chehab
2016-09-21  0:44 ` [PATCH v4 00/29] Create a book for Kernel development Jonathan Corbet
2016-09-21  9:20   ` Mauro Carvalho Chehab [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20160921062020.52cb0d32@vento.lan \
    --to=mchehab@s-opensource.com \
    --cc=corbet@lwn.net \
    --cc=greg@kroah.com \
    --cc=jani.nikula@linux.intel.com \
    --cc=linux-doc@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=markus.heiser@darmarit.de \
    --cc=mchehab@infradead.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox