all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: Jambunathan K <kjambunathan@gmail.com>
To: "Evgeny M. Zubok" <evgeny.zubok@tochka.ru>
Cc: emacs-devel@gnu.org
Subject: Re: Policy for documentation of ELPA
Date: Sun, 17 Jul 2011 15:50:15 +0530	[thread overview]
Message-ID: <81livx43a8.fsf@gmail.com> (raw)
In-Reply-To: <877h7h458x.fsf@tochka.ru> (Evgeny M. Zubok's message of "Sun, 17 Jul 2011 13:37:50 +0400")

"Evgeny M. Zubok" <evgeny.zubok@tochka.ru> writes:

> Stefan Monnier <monnier@iro.umontreal.ca> writes:
>
>>> I have written documentation (an initial version) for one of the ELPA
>>> package. The source is the texinfo file. I see that auctex provides the
>>> documentation as exported .info file along with Postscript and PDF in
>>> ./doc directory. Muse also provides the .info file. No package that
>>> provides source of documentation (texinfo files, PostScript diagrams and
>>> figures, etc). What is the current (if any) policy for documentation?
>>> Should the package also contain sources, just in case if someone want to
>>> improve the documentation?
>>
>> It should definitely contain the source (in this case the Texinfo) if at
>> all possible.
>
> And what about the documentation in compiled format? org-mode and muse
> have its own upstream development and they keep the documentation
> sources there. The developers commit only user-readable documentation
> into ELPA and they don't commit the texinfo. `debbugs' uses ELPA for
> development. So, we have no other option than to store texinfo file in
> ELPA. No problem. The main question is about the documentation in human
> readable format. ELPA contains the files as they will be installed at
> user side, right? Should I manually re-generate the final documentation
> every time I have made even the little change in texinfo file? Can I do
> it not very often? Where the documentation should arrive when the user
> installs the ELPA package?

I think you are suggesting that texi2pdf, texi2html be run on the texi
files and pdftex be run on the tex cheatsheets if any, automagically by
the ELPA infrastructure.

 Personally I think your suggestion is a very good idea and shifts the
burden away from the developer.

I think there is an opportuinity to further normalize the dir layout of
elpa tarballs (for eg, maintainers could insist that all doc files go
under ./doc etc etc)

If you are talking of doc files that are NOT DERIVED from texi files
then you can still include them under the directory of your own choosing
in the resulting tarballs.

ps: I am not much aware of the bzr version of GNU ELPA.

Jambunathan K.

-- 



  reply	other threads:[~2011-07-17 10:20 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-07-13 21:25 Policy for documentation of ELPA Evgeny M. Zubok
2011-07-16 18:57 ` Stefan Monnier
2011-07-17  9:37   ` Evgeny M. Zubok
2011-07-17 10:20     ` Jambunathan K [this message]
2011-07-18 14:59       ` Stefan Monnier
2011-07-21 16:14     ` Chong Yidong

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=81livx43a8.fsf@gmail.com \
    --to=kjambunathan@gmail.com \
    --cc=emacs-devel@gnu.org \
    --cc=evgeny.zubok@tochka.ru \
    /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.
Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/emacs.git
	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

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.