discuss: toward resumption of publishing committed and submitted documents
Subject:
Re: toward resumption of publishing committed and submitted
documents
From:
"Martin A. Brown" ####@####.####
Date:
26 Mar 2016 04:50:25 +0000
Message-Id: <alpine.LSU.2.11.1603252107470.2083@qnttre.jbaqresebt.arg>
Hello TLDP,
I'm replying to a message I sent in late January with a plan of
attack for helping TLDP resume routine publishing and acceptance of
new and updated documents.
This is an update on my progress (with your support) toward
resumption of publishing submitted documents.
> 1. automation: Be able to (re-)process and (re-)publish all of
> our existing documentation in an automated fashion.
Step 1 is now complete, with the 'ldptool' program, furnished as
part of the python-tldp package. It is installable and tested on
OpenSUSE-13.2 and Ubuntu-14.04 against our entire collection of
active source documents.
https://github.com/tLDP/python-tldp
> 3. cleanup: Simplify, revise and prune the output tree.
After this week, the automated portion of step 3 is now ready. I
have a migration script that will work in concert with the 'ldptool'
program. The migration scripts complete the retirement process for
some documents that are still visible via http://www.tldp.org/ but
were either recently declared inactive or have been inactive for
many years.
https://github.com/tLDP/LDP/tree/master/LDP/migration-2016
The parts of output tree cleanup which are not automated (or
automatable) deserve to be listed as separate work. In my opinion
the task can/should bifurcate at this point. There are two main
questions:
* How do we want to maintain and manage the static content part
of our website? [see more discussion forthcoming]
* How will we manage some sort of index into our archive?
I'll add these questions to a new list, but I think the first step
of output tree cleanup will be complete once the migration scripts
are run. If people are interested in the innards, I can write a
description of what the migration scripts are doing (and why).
> 6. formats: Consider merits of support for alternative document
> submission formats and automate processing of new accepted
> formats.
Step 6 is complete for now. We will now support Asciidoc and
DocBook XML 5.0. We will entertain the notion of supporting
additional alternate source formats, although, the question has
shifted (see earlier discussions on this list) to output formats, so
I will add item 8 (on output formats, see below).
Steps 1, 3 and 6 are now complete. That leaves:
2. deployment: Work with Serge.
4. resumption: Resumption of routine acceptance of documents.
5. metadata: Address the metadata management question.
Step 5, is still a tricky one. It looks like the earlier scripts
generated the HOWTO-INDEX by scraping the HTML outputs from the
openjade toolchain. It's textual manipulation of HTML (always a
fraught endeavor). The HOWTO-INDEX has not been updated for quite a
long time, so I think it's not worth holding up the resumption of
routine acceptance of documents.
But, after the deployment of the new software and our having the
ability to accpet new documents, I would switch my primary focus to
the question of metadata. Providing some sort of overview of our
collection (even if we replace the metadata tooling later with
something better) seems an important part of our meeting our
purpose.
In the process of the above work, I have encountered new items to
add to the list of tasks. Here they are:
7. website content: improve the ease with which we can manage and
update the static content
8. output formats: Figure out the best way to provide support for
.epub documents (from as many of our supported input formats as
is feasible).
9. archive: find some way to expose the contents of the
archive--for example old books like the sag (Systems
Administrator Guide), khg (Kernel Hacker Guide), users-guide
(another old Linux User Guide), old Linux Gazette content
If anybody has interest in taking over any of these tasks, please
let me know. My plan at this point is to focus on several things:
2. deployment
5. metadata
After that, I will probably start to ask for opinions touching on
the questions of parameters for website content management (tooling,
how to manage, static v. dynamic, whether website content management
should be separate from document management tooling, etc.).
Have a good weekend,
-Martin
[0] And, yes, JDD, pandoc does seems to be the best out-of-the-box
option--I had forgotten about it, even though several people
have mentioned it in the last two months. Thank you, JDD.
--
Martin A. Brown
http://linux-ip.net/
