From: Marek Vasut <marex@denx.de>
To: u-boot@lists.denx.de
Subject: [U-Boot] KernelDoc
Date: Thu, 27 Sep 2012 01:38:12 +0200 [thread overview]
Message-ID: <201209270138.12860.marex@denx.de> (raw)
In-Reply-To: <20120926205721.0580820032E@gemini.denx.de>
Dear Wolfgang Denk,
> Dear Marek,
>
> In message <201209262158.48495.marex@denx.de> you wrote:
> > > 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.
>
> You suggested that including kernel-doc comments was mandatory for
> patches to be accepted. And that the respective maintainer should be
> asked to fix the documentation for his code if needed. So we have to
> wait for this maintainer before the patch goes in?
>
> Ah, you say the fix has "high-prio". So we are defining exceptions
> from the rules? We should document these.
Agreed!
> > > 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.
>
> How do we do such today?
I think there's no rule for that.
> I think is kind of unfair to expect such efforts for some basicly
> unrelated changes. If I were in such a situation, I'd feel tempted to
> throw the towel.
Why would you do so ... you change interface, you document it.
> > > > 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.
>
> Still looking for ideas, sugestions, volunteers...
+1
> > > And missing or incorrect documentation would cause the patch to be
> > > rejected?
> >
> > Yes.
>
> OK, then such new policy needs to be clearly communicated and
> documented.
+1
> > > 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.
>
> Is anything like this available anywhere?
Like Tom said, compile the docs and see if they are produced ok ... otherwise,
dunno.
> Best regards,
>
> Wolfgang Denk
Best regards,
Marek Vasut
next prev parent reply other threads:[~2012-09-26 23:38 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
2012-09-26 20:57 ` Wolfgang Denk
2012-09-26 21:31 ` Tom Rini
2012-09-26 23:38 ` Marek Vasut [this message]
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=201209270138.12860.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.