Publication of all man and info pages through a web interface for each release (current status)
by ria das
Hi,
The following link will give the current status of my SoC project :
https://fedoraproject.org/wiki/RiaDas/SoC
The total project plan :
http://fedoraproject.org/wiki/SummerOfCode/2007/RiaDas
Currently the code is without any try-except block. The Extractor.py
currently converts man pages to HTML pages using the man2html command.
But I am not being able to figure out any such ready-made tool for
info pages, can anyone give me any suggestion about this?
In the current project plan, I am keeping all man and info pages as
static HTML pages. A simple web interface will show the pages
according to different fedora releases. The interface will also have a
simple option see diff of the same man pages of different releases
(here i am confused to decide whether to show the diff between roff
files or the generated HTML files). My choice : roff files.
Looking forward to comments from everyone.
Ria
16 years, 8 months
Self-Introduction: Richard Frontaine
by Richard Frontaine
Hello.
My name is Richard Frontaine and I am 41 years old.
I live in Petah Tikva, Israel and I have a PhD in psychology.
I am actually pretty new to all this Fedora contribution thingy, so as time
passes I would see what more I can do. I'm sure there's a lot more to do in
here.
I haven't done nothing like that before. Ohhh, I helped to translate Gmail
to hebrew but I didn't really do anything but to learn how to do it :)
I am pretty good in handling computers and I'm more of a software guy than
hardware. I also have very basic programming skills.
I guess maybe in the future I would like to become an ambassador, but I'm
not sure.
My GPG Key is: DDD66C62
Here is the whole block of information:
[root@localhost ~]# gpg --fingerprint DDD66C62
pub 1024D/DDD66C62 2007-07-06
Key fingerprint = F653 9FC2 FB04 45D4 47FA B048 00FB 8B95 DDD6 6C62
uid Richard Frontaine <RichardFrontaine(a)gmail.com>
sub 2048g/A86FDD7D 2007-07-06
Hope I did it right :)
Have a good day.
--
Richard :-)
16 years, 8 months
Erroneous POT changes
by Paul W. Frields
I'm starting to see some problems in CVS wherein a few of our
well-meaning L10N members are changing POT files. These POT files are
regenerated anytime the XML files change, and therefore the POT files
should not be changed manually by anyone. (That includes a document's
authors and editors, too.) Do we need to have some sort of access
control on the POT file, or would a simple admonition to the L10N list
suffice?
--
Paul W. Frields, RHCE http://paul.frields.org/
gpg fingerprint: 3DA6 A0AC 6D58 FEC4 0233 5906 ACDB C937 BD11 3717
Fedora Project: http://fedoraproject.org/wiki/PaulWFrields
irc.freenode.net: stickster @ #fedora-docs, #fedora-devel, #fredlug
16 years, 9 months
Unnecessary doc entities abound?
by Paul W. Frields
A while back, we created the ability for document modules to carry their
own specific XML entities. An editor who needs to use entities that are
specific to a document makes a per-document entities XML file, and
defines it in the module's Makefile with the ${DOC_ENTITIES} variable.
For instance, a tutorial about the program
"Supercalifragilisticexpialidocious" could have a defined general entity
MYNAME that allowed the author the ability to shorthand the program
name:
<para>This paragraph has something very
vital to say about &MYNAME;.</para>
This cuts down on typographical errors, and also ensures that if
"Supercalifragilisticexpialidocious" changes its name to "Foobarific"
later, the author or editor need only change the name in one place to
have it propagate through the document.
We used to ask for all documents to carry this file and to always define
the following entities:
&DOCNAME; (the document module name)
&DOCVER; (the document version, repeated from rpm-info.xml)
&DOCDATE; (the document date, repeated from rpm-info.xml)
&DOCID; (the document ID, which is really:
"&DOCNAME;-&DOCVER; (&DOCDATE;)" -- or for example:
"foobarific-guide-0.5 (2007-05-20)")
Other than the &DOCNAME; entity, these elements appear in rpm-info.xml,
which is a required file. Even the &DOCNAME; is of questionable value,
since we already have the document title (e.g. "Foobarific Guide") in
rpm-info.xml. The reason we created these elements originally was -- we
(I?) thought -- that we could use them to populate commonly included
snippets from the "docs-common" module.
This is incorrect. The XML standard does not allow for this willy-nilly
inclusion from different directory namespaces. We could build a lot of
crazy infrastructure to allow us to copy or link these included
snippets, but in the long run, it's simply ugly hackery and makes our
toolchain more fragile and less maintainable.
So my proposal (sorry, long time to get to the punch line): We drop the
requirement for these document entities. Document metadata then only
needs to be updated once by an author or editor making a change -- in
the rpm-info.xml file only.
This is a minor change and should not affect any current functionality
in the toolchain. No documents should be attempting to use the snippets
as they currently exist.
--
Paul W. Frields, RHCE http://paul.frields.org/
gpg fingerprint: 3DA6 A0AC 6D58 FEC4 0233 5906 ACDB C937 BD11 3717
Fedora Project: http://fedoraproject.org/wiki/PaulWFrields
irc.freenode.net: stickster @ #fedora-docs, #fedora-devel, #fredlug
16 years, 9 months
Finding man files: CVS or RPM repositories?
by Ville-Pekka Vainio
Hi,
(CC'd to docs-list)
My summer project[1] is at a stage where I need to think about finding all of
the man pages in a Fedora release. I have basic CVS integration working so
that the user can specify a package and a branch and it imports the man pages
from that package to the wiki (by downloading the source tarball). You can
read more about the status of my project from my newest weekly report[2].
But what do you think is the best way of finding all of the man pages in a
release?
- Do a "cvs -co", parse it, download every source package and search for man
files?
- Or download filelists.xml from a repository mirror, parse it to find every
package that contains man pages, then download the RPMs and extract the man
pages from them?
- Any other ideas?
And in any case, how to handle package updates?
I'm starting to be in favour of the RPM repository choice. It was pointed to
me in the comments of my blog[3] that sometimes the man files are edited in
the .spec file and so taking the files from the binary RPMS might be a good
thing.
Handling package updates would also be somewhat simple if I used RPM
repositories, yum does that all the time ;)
Thanks in advance for your comments!
[1] http://fedoraproject.org/wiki/SummerOfCode/2007/VillePekkaVainio
[2]
http://vpv.kapsi.fi/blog/2007/07/01/weekly-report-week-26-so-many-questions/
[3]
http://vpv.kapsi.fi/blog/2007/07/01/weekly-report-week-26-so-many-questio...
--
Ville-Pekka Vainio
vpivaini(a)cs.helsinki.fi
16 years, 9 months
planning next FDSCo elections
by Karsten Wade
We learned today that we cannot have two elections at the same time, due
to limitations in the voting software.
Originally, we were trying to have elections coincident with FESCo
elections. However, our plan was August, and they were going to have
them end of June, so that is hard to re-align.
Fortunately, FESCo has held off their elections. We can re-align with
them, although we have to choose different dates.
If FESCo has theirs at the end of July, which sounds likely right now,
then that puts us back in the August time-frame. To get them closer, I
recommend early in August.
20 Jul - 02 Aug (2359 UTC) :: Nominations open for two weeks
03 Aug - 13 Aug (2350 UTC) :: Elections open for ten days, including two
weekends
Thoughts?
- Karsten
--
Karsten Wade, 108 Editor ^ Fedora Documentation Project
Sr. Developer Relations Mgr. | fedoraproject.org/wiki/DocsProject
quaid.108.redhat.com | gpg key: AD0E0C41
////////////////////////////////// \\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\
16 years, 9 months
mailing lists owners
by Karsten Wade
BTW, I'm going to add all the FDSCo members as mailing list admins for
fedora-docs-list and fedora-docs-commits. Be prepared for the slight
flood; mostly it is Mailman notices at caught spam. I let these build
up then log in to the admindb and wipe them all at once. With more of
us, if everyone does a clean-up occasionally, it lightens the load on
one person considerably.
So, turn on those spam filters for the stuff that gets through. :) The
commits list (f-docs-commits) has to be an open acceptance to get mail
from CVS. :(
- Karsten
--
Karsten Wade, 108 Editor ^ Fedora Documentation Project
Sr. Developer Relations Mgr. | fedoraproject.org/wiki/DocsProject
quaid.108.redhat.com | gpg key: AD0E0C41
////////////////////////////////// \\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\
16 years, 9 months
[Fwd: Reminder -- Vote in the Fedora Board election]
by Karsten Wade
Don't forget to vote.
This is your project, your project board, and your chance to select who
speaks and acts for you.
-------- Forwarded Message --------
From: Max Spevack <mspevack(a)redhat.com>
Reply-To: fedora-list(a)redhat.com
To: fedora-announce-list(a)redhat.com
Subject: Reminder -- Vote in the Fedora Board election
Date: Mon, 2 Jul 2007 16:17:25 -0400 (EDT)
I would like to remind everyone to vote in the Fedora Board elections,
which are currently ongoing. If you are getting this message multiple
times, I'm sorry. It's being sent to various lists.
The Fedora Board's membership changes on a rotating basis. This
election is for 3 of the 9 Fedora Board seats. The Fedora Board is the
Fedora Project's "executive committee" and is ultimately accountable for
everything that happens within Fedora, and delegates responsibillity to
various sub-projects accordingly.
Information about the candidates and voting is available here:
http://fedoraproject.org/wiki/Board/Elections
Voting will end at 11:59 PM UTC on Sunday July 8th. Anyone who has
signed the Fedora CLA is eligible to vote.
Thank you,
Max
--
Max Spevack
+ http://fedoraproject.org/wiki/MaxSpevack
+ gpg key -- http://spevack.org/max.asc
+ fingerprint -- CD52 5E72 369B B00D 9E9A 773E 2FDB CB46 5A17 CF21
--
Karsten Wade, 108 Editor ^ Fedora Documentation Project
Sr. Developer Relations Mgr. | fedoraproject.org/wiki/DocsProject
quaid.108.redhat.com | gpg key: AD0E0C41
////////////////////////////////// \\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\
16 years, 9 months