From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752794AbcEaKao (ORCPT ); Tue, 31 May 2016 06:30:44 -0400 Received: from mga02.intel.com ([134.134.136.20]:10268 "EHLO mga02.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750948AbcEaKah (ORCPT ); Tue, 31 May 2016 06:30:37 -0400 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.26,395,1459839600"; d="scan'208";a="992113333" From: Jani Nikula To: Markus Heiser , Daniel Vetter Cc: Jonathan Corbet , Grant Likely , Mauro Carvalho Chehab , Dan Allen , Russel Winder , Keith Packard , LKML , linux-doc@vger.kernel.org, Hans Verkuil Subject: Re: [PATCH 00/10] Documentation/Sphinx In-Reply-To: Organization: Intel Finland Oy - BIC 0357606-4 - Westendinkatu 7, 02160 Espoo References: <877fec7gfm.fsf@intel.com> <36300F5F-C3F3-4A55-9257-788CF9F96CA4@darmarit.de> <878tyrbo36.fsf@intel.com> <5369C8B8-47F2-4B67-A314-5EB5471ABA00@darmarit.de> <87k2ibfh0x.fsf@intel.com> <6A6202B8-16E4-4EC0-9528-A79FB703FFCD@darmarit.de> User-Agent: Notmuch/0.22+12~gbdd9442 (http://notmuchmail.org) Emacs/24.4.1 (x86_64-pc-linux-gnu) Date: Tue, 31 May 2016 13:30:32 +0300 Message-ID: <87twhea59z.fsf@intel.com> MIME-Version: 1.0 Content-Type: text/plain Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, 31 May 2016, Markus Heiser wrote: > Am 31.05.2016 um 10:07 schrieb Daniel Vetter : >> 0-day builds all docs, and checks for new warnings. Even in today's >> gpu.tmpl build there's a massive pile of warnings, so yes developers >> don't look. But 0-day does, and then developers look at the nice mails >> from 0-day. It mostly works to keep out new fail I think. > > In general, I'am not very happy with workarounds like this. IMO these > are workarounds are often, rewards bunglers and punish those with more work, > who want make thinks right. There might be situations where 0-day build > is the only/best solution. But *here* we are talking about one additional > comment line the author adds, when he modify his source comments from kernel-doc > to reST markup .. IMO not very hard. That "one line" translates to nearly 50000 kernel-doc comments in more than 6000 files. If you expect people to add a tag in each file/comment, it will never happen. If we assume it's all rst, we can at least start converting. I quickly wrote a small "kernel-doc-rst-lint" script (70 lines of python) based on rst-lint [1] that runs kernel-doc on a file and reports all the kernel-doc and rst-lint errors in the output. This can be run as a "checker" in the kernel build with $ make CHECKER=scripts/kernel-doc-rst-lint C=1 and it can provide better and more direct warnings on kernel-doc/rst errors than a full Sphinx build does. BR, Jani. [1] https://pypi.python.org/pypi/restructuredtext_lint -- Jani Nikula, Intel Open Source Technology Center