guix-patches
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[bug#29438] Generating service documentation


From: Ludovic Courtès
Subject: [bug#29438] Generating service documentation
Date: Sun, 10 Dec 2017 15:29:08 +0100
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/25.3 (gnu/linux)

Hi Clément,

Clément Lassieur <address@hidden> skribis:

> It's a bit sad that most services' docstrings are not in sync with the
> .texi file, it would be great to have an automated mechanism to update
> the documentation.  I use a hackish Emacs snippet to maintain Prosody
> documentation, but something like "make generate-documentation
> <service>" would be much better.  I'll think about it.
>
> @c The following documentation was initially generated by
> @c (generate-documentation) in (gnu services messaging).  Manually maintained
> @c documentation is better, so we shouldn't hesitate to edit below as
> @c needed.  However if the change you want to make to this documentation
> @c can be done in an automated way, it's probably easier to change
> @c (generate-documentation) than to make it below and have to deal with
> @c the churn as Prosody updates.
>
> I don't really agree with this comment that can be found in several
> places in our documentation.  I believe that when there is a
> (generate-documentation) procedure, manual edits shouldn't be
> encouraged.  But it's probably not worth updating it while there is no
> easy way to automatically generate the documentation.

It’s complicated.  Automatically-generated documentation can be useful
as a reference, but it doesn’t really help you get started.  It’s
typically a very unfriendly, Javadoc-style, dump of functions/fields.
It think that’s what this comment is about: generated doc is a start,
but it’s not doing much of a service to our users.

Now, if the choice is between terse-and-outdated doc and
terse-but-automatically-updated doc, the latter is preferable.  It’s
just not ideal IMO.

>> Also, I was thinking that ‘guix system search’ could display
>> field/default-value pairs.  I’m not 100% sure it’s a good idea because
>> that could be very verbose.
>>
>> Thoughts?
>
> It would be verbose indeed, and if people want to have details about
> fields and default values, they can search the manual.

Yeah.  I was thinking that it might be helpful, let’s say if you’re
using openssh-service-type and you don’t remember the exact name of an
option having to do with authentication.  Dunno.

Thanks,
Ludo’.





reply via email to

[Prev in Thread] Current Thread [Next in Thread]