public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: "Theodore Y. Ts'o" <tytso@mit.edu>
To: Markus Elfring <Markus.Elfring@web.de>
Cc: Enrico Weigelt <lkml@metux.net>,
	linux-doc@vger.kernel.org, kernel-janitors@vger.kernel.org,
	LKML <linux-kernel@vger.kernel.org>
Subject: Re: Improving documentation for programming interfaces
Date: Wed, 8 Jan 2020 11:14:28 -0500	[thread overview]
Message-ID: <20200108161428.GA263696@mit.edu> (raw)
In-Reply-To: <748b8572-a3b3-c084-e8e3-de420f53e468@web.de>

On Wed, Jan 08, 2020 at 01:40:45PM +0100, Markus Elfring wrote:
> 
> I propose to encode helpful information into macro calls as needed
> for the C programming language.

Perhaps it would be useful to for you to express what you are
proposing in the form of a patch?  That way people can see how
disruptive such changes might be, and how hard it might be to maintain
them.  That's on the "cost" side of the equation.

On the "benefits" side of the equation, is there are ways in which it
will directly benefit the kernel developers who will need to review
the patches and review the annotations, that can be demonstrated
immediately?  Not in some abstract way, or "when I my research work is
completed", but a very concrete way that will be obvious to those of
us who are still not completely convinced?

If the costs are very small, then the requirement for demonstrating
great benefits will also be small.  But if the costs are large (e.g.,
widespread renaming of huge numbers of functions, adding a lot of
extra complexity into code paths, use of silly/stupid names such as
"TransactionAwarePersistenceManagerFactoryProxy"), then need to show
benefits commensurate with such costs will also be great.

	 	      	   	      - Ted

  reply	other threads:[~2020-01-08 16:14 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-12-20 13:30 Improving documentation for programming interfaces Markus Elfring
2019-12-20 15:19 ` Theodore Y. Ts'o
2019-12-20 16:23   ` Markus Elfring
2019-12-20 17:17     ` Theodore Y. Ts'o
2019-12-20 18:00       ` Markus Elfring
2020-01-08 12:04   ` Enrico Weigelt, metux IT consult
2020-01-08 12:40     ` Markus Elfring
2020-01-08 16:14       ` Theodore Y. Ts'o [this message]
2020-01-08 16:55         ` Markus Elfring
2020-05-01  7:20         ` Markus Elfring

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=20200108161428.GA263696@mit.edu \
    --to=tytso@mit.edu \
    --cc=Markus.Elfring@web.de \
    --cc=kernel-janitors@vger.kernel.org \
    --cc=linux-doc@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=lkml@metux.net \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox