Em Tue, 20 Sep 2016 18:44:54 -0600 Jonathan Corbet <corbet@xxxxxxx> escreveu: > On Mon, 19 Sep 2016 08:07:34 -0300 > Mauro Carvalho Chehab <mchehab@xxxxxxxxxxxxxxxx> 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 -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
