Upcoming Fedora 13 Schedule Tasks
by John Poelstra
Start End Name
Wed 18-Nov Tue 04-May Create POT files for All Guides
Mon 19-Apr Mon 26-Apr Port diff wiki content to Publican
Mon 26-Apr Thu 06-May Daily builds of Final guides for Translation
Mon 26-Apr Mon 26-Apr Generate GA Release Notes POT files for Translation
Tue 27-Apr Mon 03-May Review and correct GA Release Notes (daily
builds html)
Tue 27-Apr Mon 03-May Build GA release note htmls for Translation
Thu 29-Apr Thu 29-Apr Remind Translators of GA Release Notes Deadline
in 4 days
Mon 03-May Tue 11-May Create GA Announcement (Docs & Marketing)
Mon 03-May Wed 05-May Build fedora-release-notes.rpm
Tue 04-May Tue 04-May Development: Final Freeze
Thu 06-May Thu 06-May Push updated rel-notes RPMs to Updates repo
Fri 07-May Sun 09-May Final Build All Guides: All Languages
Fri 07-May Mon 17-May 0-Day rel-notes build updated rpm
Fri 07-May Mon 17-May 0-Day rel-notes update docs.fp.org
Fri 07-May Mon 17-May 0-Day rel-notes generate POT
Mon 10-May Mon 10-May Publish all guides to docs.fp.o
(html,html-single,pdf)
Tue 11-May Tue 11-May Fedora 13 Final Go/No-Go Meeting (20:00 EST)
Wed 12-May Wed 12-May Fedora 13 Final Release Readiness Meeting
14 years
Updated en_US release notes?
by Paul W. Frields
Our wiki beats are supposedly frozen now for content changes. We are
set to deliver the final POTs to L10n on Monday.
That means that over the next few days, we need to look over all the
beats on the wiki, and perform the following (not too difficult)
procedure:
1. Find out if anything's changed there by looking at the wiki page's
history
2. If so, compare to the XML file for that beat in the release-notes
'master' branch in the git repository.
3. If the change isn't already in there, make the change to the XML,
being careful not to disturb existing text if at all possible (to make
life easier for translators).
4. Mark that beat as done on the beats page:
https://fedoraproject.org/wiki/Documentation_Beats
We'll go over some of this tonight at the content party right after
the Docs meeting. The Docs meeting happens at 2300 UTC, and is
scheduled for an hour. We'll meet in #fedora-docs on IRC afterward.
--
Paul W. Frields http://paul.frields.org/
gpg fingerprint: 3DA6 A0AC 6D58 FEC4 0233 5906 ACDB C937 BD11 3717
http://redhat.com/ - - - - http://pfrields.fedorapeople.org/
Where open source multiplies: http://opensource.com
14 years
docs.fedoraproject.org redesign -- very long!
by Ruediger Landmann
For at least the last year or so, we've been looking for ways to make
docs.fedoraproject.org (d.fp.o) more usable for our readers and less
onerous for our contributors. At the last docs meeting,[0] nb outlined a
proposal to replace the current CVS mechanism, and I presented a brief
demo of what publishing looks like with the forthcoming Publican 2.0.[1]
To further the discussion, I thought I'd present the options a bit more
completely here.
Sorry this is so very wordy! I threw together some graphics to accompany
this post that hopefully might make it a bit more digestible.
Please have a read and share your thoughts.
Cheers
Rudi
================================
OPTION 0 -- What we have now -- CVS + PHP
================================
1. Writers[2] pull down the source code of a doc from a repo (mostly
git) and at least some part of d.fp.o site as stored in a CVS repo.
Unless you're working on multiple docs, you only need the directory that
corresponds to your book, not the entire site.
2. Writers build the book from source on their local machines, and copy
the Publican output into their local copy of the d.fp.o directory for
that book. They also hand-edit PHP files as needed to provide the index
pages.
3. Writers perform CVS voodoo to add and commit the files back up to the
CVS repo, and tag the files LIVE. Within a few hours, the web server
picks up any files tagged LIVE in the CVS repo and publishes them.
PROBLEMS:
1. Editing the PHP index files by hand is onerous and seriously prone to
error. Everyone who has worked on this has routinely made mistakes
keeping track of which book in which format in which language goes where.
2. The CVS process is notoriously temperamental, unforgiving, and prone
to error. Mistakes are frequent, and correcting them is difficult and
frustrating (and in some cases, not even possible).
================================
OPTION 1 -- Proposal from Infra -- git + static HTML
================================
1. Writers pull down the source code of a doc from a repo (mostly git)
and a git repo containing the entire d.fp.o website.
2. Writers build the book from source on their local machines, and copy
the Publican output into the local copy of the git directory for that
book. They also hand-edit html files as needed to provide the index pages.
3. Writers commit the files back up to the d.fp.o git repo. Within a few
hours, the web server synchronises with the repo and publishes the new
files.
ADVANTAGES:
1. Replacing CVS with git eliminates the single greatest source of
failure and frustration.
2. The tools available to edit static html index files are more powerful
and more user-friendly than editing PHP in a text editor, so mistakes
are less likely to occur.
DISADVANTAGES:
1. The initial git clone is massive -- something like 2 GB -- and this
will only grow bigger over time.
2. Indexes are still built by hand.
================================
OPTION 2 -- Publican
================================
Note technology demonstration available at
http://publictest8.fedoraproject.org/fedoradocs/public_html -- hurried,
and slightly broken in places
1. Writers ssh into a remote system (let's call it the "build system"
and pull down the source code of a doc from a repo (mostly git) onto
that system.
2. Writers build the book with Publican on the build system, and run
the "publican install_book" command. Publican adds the book to a local
copy of d.fp.o and automatically rebuilds the site index.
3. At regular intervals, any new or changed files in the version of
d.fp.o on the build server are copied to the web server, using scp or
rsync or something similar, initiated either on the build server end or
the web server end.[3]
ADVANTAGES:
1. Writers are finally completely free from the two most onerous and
error-prone parts of the publication process: using a version-control
system as a publishing tool, and having to rebuild indexes by hand. Even
if a book itself is misconfigured, screwups are contained to a single
book in a single version in a single language, unlike some incidents
we've had with hand-edited PHP.
DISADVANTAGES:
None of which I'm aware, however we'll need some new infrastructure in
place and we'll all no doubt make mistakes while getting used to a new
way of doing things.
================================
OPTION FOR TOMORROW -- Publican + Koji
================================
1. Writers pull down the source code of a doc from a repo (mostly git)
2. Writers run "publican package" on their local systems with an option
that tells Publican to upload the SRPM package to a Koji instance. Koji
builds the package and places it in a repo.
3. At regular intervals, the web server pulls any new docs packages from
the repo and installs them. Documentation packages built with Publican
automatically install into subdirectories of /var/www/html/ and
regenerate any Publican site index present.
ADVANTAGES:
1. Publishing is completely automated. This is actually the job that
Publican was designed to do and pretty much how it's been running
internally within Red Hat for years. Writers and translators can focus
on writing and translating and leave everything else to the machines.
2. Since the documentation is going to a repo, Fedora users world-wide
could yum install docs packages from this repo. We might also be able to
take advantage of the new langpacks feature in yum to help users find
documentation in their own language.
DISADVANTAGES:
No disadvantages of which I'm aware, but the current stumbling blocks to
implementing such a system right now are:
1. Publican doesn't yet support sending packages to arbitrary Koji
instances! So this would require some code changes to Publican. Since
Publican already supports Red Hat's Brew system, I suspect these are
relatively minor.
2. We would need a Koji instance on which to build docs. Writers and
translators who are trusted to publish docs would need to be approved as
packagers on that Koji instance. In a perfect world, this would be the
same Koji instance that the Fedora Project uses already to build
software packages. However, most writers and translators do not need to
or want to package software. We would need some administrative changes
within the project that would approve certain writers and translators to
build docs packages only. We would also likely need a different package
approval process for docs, as docs packages would quickly overwhelm the
existing system.[4] Failing to get these admin changes, we would need a
separate Koji instance somewhere, and need Infra to maintain it for us.
================================
Notes
================================
[0] minutes --
http://lists.fedoraproject.org/pipermail/docs/2010-April/012130.html
[1] Publican 2.0 is still under heavy development, but I have (unsigned)
packages for Publican 1.99 and its web component available from my
fedorapeople page: http://rlandmann.fedorapeople.org/publican/ and you
can find instructions for the new web stuff on Jeff Fearn's page:
http://jfearn.fedorapeople.org -- please download and experiment!
However, if you're involved in building or publishing F13 docs, please
do not use Publican 1.99 for this, and in particular, do *not* update
POT or PO files for current work with Publican 1.99!
[2] I say "writers" here, but the same applies to translators, although
to date, translators have not generally been involved in publishing
their work. One advantage of rethinking how we publish is to allow
translators and language teams direct control over their work, without
making them rely on writers as "gatekeepers" for their docs.
[3] Technically, there's no reason why the build server and web server
need to be two separate machines, or why the "publican install_book"
command couldn't write directly to a publicly accessible directory on
the web server. I've suggested separating them mainly out of paranoia,
but maybe I'm being overly cautious?
[4] Hopefully in the context of this whole workflow, Publican's
insistence on packaging languages one-at-a-time and on including version
numbers in package names makes more sense -- it's these distinctions
that produce the table of contents for the site. It also illustrates why
a different package approval process would be necessary for docs -- 15
books in up to 12 regularly-translated languages is up to 180 new
packages for each Fedora release...
14 years
Self-Introduction
by William Morris
-----BEGIN PGP MESSAGE-----
Charset: ISO-8859-1
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/
hQIOA6Itd7kzSi5xEAf/SauXaDnL34SqXxncNlZflQNJhnT/7h19qDV10nJHtbLJ
2dScYh5Cdno5Worh+yvQ5y7VWW7mOHz20XhRDzpc3hb47kzRotOaXBb1FFqBKBP1
tmKMuFPJRwZrxKL6kCuCCQWCe2DQJF6ejJZkP0J36h3MgdRi3qM0wJGseAp3ajDF
8ERebLZuMBjIVOAbyYacYdkgXWhMA8DpJ5al4OWyjIL5Znh5d7ETXJ6icSQ3+mFh
xWc6+oFC925njya4teMF+p3KAylBbK6YFYMqGZQvXxhpaj2sjDfodzlSEKywevxP
Yk2UNRwegpBpWQnmVTSWXJh7OMgpbi74ccsUvvQpNAf9HYKTIh4Lci5jMwgD263Z
neL9H/XW9clAiHlnpyzdwk9Oc/0dpKIG2tqXNhhyqnTaBzdAe2o/86Yj4IKJ1o1w
bEHnoAMy4FvUbupUhZ7AAZBL3e2x/eua4HL+w0M9doit6ro7TqHEtXsiSryucEne
6ln3ua4ubiJ4J+bpduGc4FZN1f3p5PkgM5WCovOLiv/g0rJBENigDrszQ212WfJq
LPF6ip7yycbW/BvxVO/ZKuuVrZoALqB03NJKw0DymqaWCdlEUBZgrp+dUh/t4d6Y
GrZTCEn3yVnmkTImddKnBTOcaIFGdB3dOmKtziSZztyc8Z621/ZSejDp8JCs5rnD
stLpAUkvt+pr4EEj1e6J9u/H01aWqfHFW55xp/R2qqqpmeph+w9V9yv9sSHEdl0P
rGquhxrcSLwskLvRUHOghUudVl3mCbFqYZFwfwxLmfBwso8e/QhW562bF9Yg+VkZ
KQUGBIWrTbTrUEUM/s2vtGTaFbVxAuT1aFcBGG8oHja9Hf/pJ4590YFXTAY+vYOQ
jmS2CBSaYlxvRm9g1oq2i8zhb5DEVXsF0mH/gg1yNpptuZoSwE9n1o5F5QcklfeT
ot8s+EtnSLIXt2m/Ad9wIEqDwZGjyaJR5S39gS9ExkXNaa7Qw+06wmVK1wu9cB6W
SzqKIFFynt5BpOLkqYmD3nddSp7FmgDu2ho4PxelBMzTXdhEpLukUys1hPQqkYnn
XiYHPkYda4tuBzdhvNxLOUDW2X8ktQ69wx1qadmlY+ABMepWseR92E7Uo91NwFWr
nIvEGOFpJzqNMC6oiN5J47MN8V3egsoZfr2Do0J0hMXy4n9Nu24QIFJkuXYjcGIo
OEajw4r6dMXCFxdD/IsWhss+mmibxIO9N62RkNftdIYJQARADlKVFsCG9PdEvsEr
w86ne0b9YX3G/bRGFP9I2AXkcLEIotdfww9xa2vjo4zQO4w7zo6yKt1U71+ODh4n
VzEceVhOHzHmoDLij8ppgEPKO3hXFYYoX8jV2MEU2dr5T5h5wXDqZno7bmWbk7UP
h/RAb9oORmbtB+luTD8tepywA1NO6eGaGO60rgLV7a+Cma/OBI47/p65R95eoLUF
//lvjC0F8tvNdcaTIDv/5CuRBD6Zq5sAVCPpqWalJY3lNqTNlJXUiMZBpl8t170G
vkANLXKkAy5iuI3Rpg==
=Pq/Z
-----END PGP MESSAGE-----
14 years
Newcomer from Russia
by Evgeny Pashkov
Hello,
my name is Evgeny Pashkov. I am from Russia, Nizhniy Novgorod and I like to join the Fedora team. I use linux for a few years and I want improve my experience in it. There are some notes about my experience: installation and configuration, Shell Scripting, configuration http and proxy, the C programming language and a few other development tools such as gcc, svn, etc. How I can join the group and how I can find sponsors?
--
Best regards,
Evgeny Pashkov
14 years
Re: User Guide - update
by Susan Lauber
On Wed, Apr 21, 2010 at 2:00 PM, Susan Lauber <laubersm(a)fedoraproject.org>wrote:
> I finally got around to putting the work that lewis41 did on the Connecting
> to the Internet chapter into the master branch of the the User Guide.
> Luigi did a great job getting the draft together which made it a pretty
> simple task once I sat down and went through it. Thank you!
>
> Luigi,
> Can you please look it over and make sure that I did not change the meaning
> of anything or leave out any critical portions.
>
> All,
> Anyone else who can proofread for prose, grammar, and even spelling - that
> would be appreciated.
>
I have also finished the Office Tools update. Proofreading is greatly
appreciated.
I still plan to grab updated screen shots for the desktop tours then I think
I can push an update to trans before the end of the week.
No one has stepped up to handle an addition of a Printing unit.
Rudi - do I need to be doing anything with the contributor list about the
last round of translation folks? I made sure to get in everyone that I know
helped with the writing/editing of the update but that is all.
Thanks,
Susan
--
Susan Lauber, (RHCX, RHCA, RHCSS)
Lauber System Solutions, Inc.
http://www.laubersolutions.com
gpg: 15AC F794 A3D9 64D1 D9CE 4C26 EFC3 11C2 BFA1 0974
14 years
Member application
by Misha Shnurapet
Hello, Docs Team!
I'm looking for membership in the Docs project. I have been involved in
translation of tools and websites for Fedora and would like to enter the
Docs group (application pending).
My profile and my contact data are located at
https://fedoraproject.org/wiki/User:Shnurapet
Thank you.
--
Best regards,
Misha Shnurapet
14 years
Guinea Pig Needed
by John J. McDonough
As you may be aware, the Technical Notes are produced almost entirely
automatically. What you may not know is that, with the exception of the
first section, they are produced entirely from scratch.
Up until now, I've been the only one producing these. This isn't good.
Someone else should be able to make these notes in my absence.
To that end, I've tried to document the process, and heavily script it.
Trouble is, sometimes my writing sounds more like Klingon than English,
and I can't always tell the difference.
What I need is for someone to follow those instructions and make an
updated Technical Notes, perhaps enhancing the instructions along the
way.
This process is pretty quick, perhaps 15 minutes or so. If you would
like to try it out, my instructions are in the git for technical notes.
The direct link is:
<http://git.fedorahosted.org/git/?p=docs/technical-notes.git;a=blob_plain;...>
We actually need an update in the next couple of days, and it would be
good if that update came from someone other than me.
Thanks
--McD
14 years
Beats that come and go
by John J. McDonough
There has been some question lately about beats that come and go. For
Rudi and I, who perhaps get a little broader view, it is pretty obvious,
but for those who are only working on parts of the Release Notes, it
seems a little mysterious.
Sometimes a beat doesn't have any content for a particular release of
Fedora. In general, we strike out those beats on the beat page. If we
discover later that we need that beat, we simply remove the strikeout.
What is perhaps less obvious, is that there is an XML file for every
beat in git. These files start out their life having only the title for
the section and a comment with a link to the beat page (that purple line
in the drafts).
The en-US/Release_Notes.xml file is nothing more than a long list of
include statements. When a beat is struck out on the wiki, the include
statement is commented out in Release_Notes.xml. If we later discover
that there is a need for the beat, we just uncomment the include
statement.
This came up most recently with the Power PC. Last release there wasn't
much in the way of architecture-specific content, so we didn't expect
any this time. As a result, these files were commented out in
en-US/Release_Notes.xml. However, this release the Power PC becomes a
secondary architecture, something that certainly needs to be mentioned
in the Release Notes.
Folks working on converting the wiki noticed that there was no section
for architecture specific notes, even though there was a wiki page for
that. Once we have some content, we will simply uncomment the include
statement and the architecture specific section will show up again.
By the way, that purple line with the link to the beat, as well as the
Draft watermark, will be gone for the final release. They are
controlled by a "show_remarks" line in publican.cfg, and a status
parameter on the "article" tag in Release_Notes.xml.
--McD
14 years