Re: [Ksummit-discuss] [TECH TOPIC] Documentation

On Thu, Jul 09, 2020 at 08:29:14PM +0300, Mike Rapoport wrote:
> On Thu, Jul 09, 2020 at 09:59:46AM -0700, Joe Perches wrote:
> > On Thu, 2020-07-09 at 15:11 +0300, Mike Rapoport wrote:
> > > On Thu, Jul 09, 2020 at 04:42:58AM -0700, Joe Perches wrote:
> > > > On Thu, 2020-07-09 at 12:21 +0200, Mauro Carvalho Chehab wrote:
> > > > > Em Thu, 18 Jun 2020 07:40:22 -0700
> > > > > Joe Perches <[email protected]> escreveu:
> > > > > 
> > > > > > On Thu, 2020-06-18 at 12:04 +0300, Mike Rapoport wrote:
> > > > > > > if a patch breaks the sync between the code and the
> > > > > > > kerneldoc can it be detected by checkpatch.pl?  
> > > > > > 
> > > > > > No, it can not.  Not directly.
> > > > > 
> > > > > Well, perhaps checkpatch.pl could run:
> > > > > 
> > > > > 	./scripts/kernel-doc -none
> > > > > 
> > > > > if it finds "/**" on a patch, showing the warnings produced by it, if any.
> > > > 
> > > > checkpatch runs on patches.
> > > > Use the tools that are designed for this instead.
> > > 
> > > The problem is that people usually do run checkpatch and do not run
> > > kernel-doc. That's where the idea to somehow put documentation checks
> > > into checkpatch came from.
> > 
> > I much prefer this patch:
> > https://lore.kernel.org/patchwork/patch/1260408/
> 
> I don't see how it will help reducing amount of the kernel-doc warnings
> and how it'll make people to check if their patch introduces new ones...

It seems like 0-day and the like would be a better solution, since
they know how to apply the patch, run tools on the sources as a whole,
and look for new warnings mixed in with older warnings.

    Andrew
_______________________________________________
Ksummit-discuss mailing list
[email protected]
https://lists.linuxfoundation.org/mailman/listinfo/ksummit-discuss