mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Charles Samuels <charles@kde.org>
To: linux-kernel@vger.kernel.org
Subject: Re: LDP / KDP?
Date: Wed, 18 Jul 2001 09:36:48 -0700	[thread overview]
Message-ID: <200107181636.JAA24824@altair.dhs.org> (raw)


Well, upon reading the output produced from a make htmldoc in the kernel
source, I've been rather (read: very) discouraged.

I'm not sure there'd be much of a "market" for this, seeing as how much more
complete the inline-kerneldocs will be.

_still_, I like my format more, it seems like it'd be much easier to search,
and I think the format is much more ideal than docbook (which I have worked
with)

e.g., an example data file: http://derkarl.org/kerneldoc/data/init_timer.kd

And of course, I'm making no effort in preventing others from "syndicating"
these data files.  With which it should be simple enough to generate a
printed form, and other formats from.  In other words: it's a really easy
parse.

But the main problem is, it will be easier for the actual writers of the code
to maintain their docs inline, which will severely slow the acceptance of
this.  So, it's a choice between inline docs and this.  If there's any
approval of this ("officially"?), then I'de be open to discuss moving this to
something LDP-sanctioned, but of course, I wouldn't want to remove the
versatility that I have so far.

However, the main reason I didn't use docbook at first was _because_ I wanted
the versatility, and I didn't want something that behaved like a book.

e.g. 
 http://developer.kde.org/documentation/library/2.0-api/classref/kdecore/

This documentation _is_ inline to the code (in the headers), generated via a
perl script "kdoc".

On Wednesday 18 July 2001 08:50 am, you wrote:
> Charles Samuels (charles@kde.org) wrote:
> (I'm only quoting your whole message because I'm
> cc'ing it to discuss@linuxdoc.org.)
>
> Have you considered writing this as an LDP Guide?
>
> Advantages:
> * Harness the incredible power of a virtual army of
> LDP volunteers. (Well, a virtual platoon...)
> * The docs become print-ready as well.
> * DocBook is a standard! Yay standards!
> * Use the already-present distribution network the LDP
> has in place.
>
> Disadvantages:
> * Your formatting looks spiffier than the LDP
> stylesheets.
> * You'd have to rewrite what you have.
> * DocBook is not tailored to your purposes.
> * Multiple versions will exist throughout the world.
>
> I believe it's an alternative worth considering. I'd
> be willing to convert what you already have to
> DocBook.

-------------------------------------------------------

             reply	other threads:[~2001-07-18 16:37 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2001-07-18 16:36 Charles Samuels [this message]
2001-07-18 18:02 ` John Levon
     [not found] <200107181626.JAA24740@altair.dhs.org>
2001-07-18 16:29 ` gdrago23
  -- strict thread matches above, loose matches on Subject: below --
2001-07-18 16:10 gdrago23

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=200107181636.JAA24824@altair.dhs.org \
    --to=charles@kde.org \
    --cc=linux-kernel@vger.kernel.org \
    /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

all inboxes | Powered by JetHome®