From: Marek Vasut <marex@denx.de>
To: u-boot@lists.denx.de
Subject: [U-Boot] KernelDoc
Date: Wed, 26 Sep 2012 21:58:48 +0200 [thread overview]
Message-ID: <201209262158.48495.marex@denx.de> (raw)
In-Reply-To: <20120926195412.AC7B32031A9@gemini.denx.de>
Dear Wolfgang Denk,
> Dear Marek,
>
> In message <201209261726.55611.marex@denx.de> you wrote:
> > > - Will we make this mandatory? So that we will reject all new code
> > >
> > > that is not documented according to kernel-doc rules?
> >
> > Yes please, make it mandatory. Otherwise people won't obey and the
> > documentation will suffer ... and all this would be meaningless.
> >
> > > - If so, what does that mean for patches that touch existing code?
> >
> > Ask the current custodian to annotate their code.
>
> Judge from previous experience: how well will this work?
I would hate to make anyone unhappy by commenting on this ;-)
> And what do we do if it doesn't work?
Is there anything we can do? It's a community project, the project is only as
good as the community.
> Or if you want to get your critical bug fix
> in now, but the custodian promises a doc patch for half a year later?
I cannot parse this. I agree the critical fix has a high-prio.
> > > If I change the major part of an existing function (without changing
> > > it's calling interface), am I obligued to add kernel-doc comments?
> >
> > Yes. Even though major vs. minor change seems pretty vague, common sense
> > shall be applied here.
> >
> > > If I change the calling interface, must I add documentation then?
> >
> > Of course, yes.
>
> Didn't we agree that we want to make it easier for people to
> contribute code? If somebody who just wants to improve a small detail
> in the code is now not only enforced to fix the coding style, but
> _also_ document the whole file, this will probably not exactly attract
> new contributors.
Of course. But if someone fixes the calling interface, how are we supposed to
know what does new parameter do? It must be documented.
> > > - What sort of documentation do we generate?
> >
> > None for starters, since it will be incomplete. I would postpone the
> > generation as a stage 2 here.
>
> Don't, that will fire back later, then.
>
> > > How can we make clear
> > >
> > > that for a long, long time it will cover only a small fraction of
> > > the actual code, eventually even parts of some source files?
> >
> > Pardon me, but I don't follow here. It will certainly for a while cover
> > only small parts of U-Boot code. We need something like
> > "kernel-janitors" here :-)
>
> I agree. We could need all kind of help for at least a dozen of
> tasks. Where do we find these? And for free?
This is a problem we have for a while.
> > > - Who will be responsible for maintaining the documentation?
> >
> > I believe for now we should only focus on using this as a standardized
> > method of anotating functions. The reviewer of the patch shall check if
> > the patch is correct incl. the documentation, as usual.
>
> And missing or incorrect documentation would cause the patch to be
> rejected?
Yes.
> Can such checking (all functions have a kernel-doc comment, which
> covers the return value and all arguments) be done automatically, say
> throuch checkpatch?
I would love to see this.
> Best regards,
>
> Wolfgang Denk
Best regards,
Marek Vasut
next prev parent reply other threads:[~2012-09-26 19:58 UTC|newest]
Thread overview: 38+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-09-25 20:46 [U-Boot] KernelDoc Marek Vasut
2012-09-26 6:50 ` Prabhakar Lad
2012-09-26 7:12 ` Wolfgang Denk
2012-09-26 7:23 ` Prabhakar Lad
2012-09-26 10:07 ` Wolfgang Denk
2012-09-26 7:17 ` Wolfgang Denk
2012-09-26 15:26 ` Marek Vasut
2012-09-26 18:50 ` Joe Hershberger
2012-09-26 19:05 ` Marek Vasut
2012-09-26 19:54 ` Wolfgang Denk
2012-09-26 19:58 ` Marek Vasut [this message]
2012-09-26 20:57 ` Wolfgang Denk
2012-09-26 21:31 ` Tom Rini
2012-09-26 23:38 ` Marek Vasut
2012-10-01 8:54 ` Wolfgang Denk
2012-10-01 9:07 ` Marek Vasut
2012-10-01 10:35 ` Wolfgang Denk
2012-10-01 10:37 ` Marek Vasut
2012-10-09 22:49 ` Tom Rini
2012-10-09 23:35 ` Marek Vasut
2012-10-14 20:26 ` Marek Vasut
2012-09-26 20:00 ` Tom Rini
2012-09-27 6:19 ` Stefan Roese
2012-09-27 17:26 ` Tom Rini
2012-09-27 17:28 ` Fabio Estevam
2012-09-27 23:50 ` Graeme Russ
2012-09-28 0:28 ` Marek Vasut
2012-09-28 0:28 ` Scott Wood
2012-09-28 0:44 ` Marek Vasut
2012-09-26 19:05 ` Tom Rini
2012-09-26 19:10 ` Marek Vasut
2012-09-26 19:46 ` Wolfgang Denk
2012-09-26 19:54 ` Marek Vasut
2012-09-26 20:49 ` Wolfgang Denk
2012-09-26 23:36 ` Marek Vasut
2012-09-26 19:57 ` Tom Rini
2012-09-26 23:39 ` Marek Vasut
2012-09-28 19:48 ` Marek Vasut
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=201209262158.48495.marex@denx.de \
--to=marex@denx.de \
--cc=u-boot@lists.denx.de \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.