CVS vendor and release tags
by Paul W. Frields
On Mon, 2005-05-16 at 00:04 -0700, tuxxer wrote:
> OK, did some preliminary commands and they seem to work (they all
> failed, actually, but I was querying modules that *shouldn't* exist
> (yet), etc. so I got results that I more or less expected). So my n00b
> question is this:
>
> How do I do my initial import of the hardening guide?
>
> I've read the CVSUsage WiKi, and (what I thought were) pertinent
> sections of the Documentation Guide, as well as the CVS general
> documentation. I haven't been able to glean a command line that works.
> Help?
I'm taking this to the list since it involves a general policy and
procedural concern, which is CVS tags. In the past, Karsten and Tammy
imported my sources, since there was no One True CVS access. In
general, the command is:
cvs import <repodir> <vendor-tag> <release-tag>...
What are the vendor and release tags that people should be using to
import? The answers should probably come from a consensus of three
individuals -- Karsten (has done lots of importing before IIRC), Tommy
(FDP CVS maintainer), and Tammy (resident CVS goddess).
We should probably figure out how to do this rationally to allow for
branching by Core release (viz. usb-hotplug tutorial). I don't know how
these tags affect the structure of the repository, so I don't have any
substantial ideas to offer. As long as the tags don't make it awkward
for the project to expand to cover things outside Core (such as Extras),
nor to handle translations, nor to branch, it's just a matter of these
folk putting their heads together, with help from other list members.
--
Paul W. Frields, RHCE http://paul.frields.org/
gpg fingerprint: 3DA6 A0AC 6D58 FEC4 0233 5906 ACDB C937 BD11 3717
Fedora Documentation Project: http://fedora.redhat.com/projects/docs/
18 years, 11 months
.cvsignore files
by Paul W. Frields
I saw a .cvsignore pop up in the documentation-guide CVS this afternoon
which ignores the HTML build directory. Personally, I like having the
HTML build directory *not* ignored; it's a good reminder for me to check
the build before I do a commit. Since, like all good CVS commandos in
training, I do a lot of "cvs up," it reminds me to build often.
If folks want to use this feature locally, by all means, do so! Simply
make sure your local .cvsignore has an extra line that just reads
".cvsignore" so you don't end up getting a new and just as annoying CVS
message. :-)
In any case, there's probably no overriding reason to set a policy on
this issue; the document owners should dictate what's done in their
particular sandboxes. As the guy who's apparently going to spend the
most time herding the Documentation Guide in the coming months, I will
probably remove documentation-guide/.cvsignore at some point unless
there are strenuous objections.
--
Paul W. Frields, RHCE http://paul.frields.org/
gpg fingerprint: 3DA6 A0AC 6D58 FEC4 0233 5906 ACDB C937 BD11 3717
Fedora Documentation Project: http://fedora.redhat.com/projects/docs/
18 years, 11 months
Taking screenshots
by Tommy Reynolds
I've noted that some screen shots include the window decorations, others do not.
The "Documentation Guide" does not address it.
Personally, I vote for no borders.
What is the list's pleasure?
18 years, 12 months
including small bits of XML as entities
by Karsten Wade
Paul was asking me this morning ...
"I am going to ask quaid if he can figure out a way to get that XML
chunk included without the surrounding <chapter>, so it can be included
also as a <section> somewhere else, while allowing easy editing in
Emacs"
This was in reference to the common file cvs-en.xml in
the /cvs/docs/common module.
You can put _anything_ that is valid XML in a file and call it as an
entity. Wherever you call the entity, it must be valid or an error will
occur.
For example, you can have a stand alone <section> in a single file. If
you define the part within the fedora-entities-en.xml file or within
your parent XML file as, for example:
<!ENTITY FOO SYSTEM "./foo.xml">
Then you can call it with &FOO; anywhere that the <section> is otherwise
legal.
Similarly, the contents could be:
<para>
This is a common thing I put all over the place so have made an entity
for it.
</para>
You can put just that XML in a file and call it as an entity. It must
be legal wherever you call it. So, this would be a legal usage:
<para>
Here is something to read:
</para>
&FOO;
<para>
Got that?
</para>
This would _not_ be legal and would generate errors upon building or
using Emacs to validate the file with C-c C-v:
<para>
Here is something to read: &FOO; Got that?
</para>
- Karsten
--
Karsten Wade, RHCE * Sr. Tech Writer * http://people.redhat.com/kwade/
gpg fingerprint: 2680 DBFD D968 3141 0115 5F1B D992 0E06 AD0E 0C41
Red Hat SELinux Guide
http://www.redhat.com/docs/manuals/enterprise/RHEL-4-Manual/selinux-guide/
18 years, 12 months
Self Introduction: Binh Nguyen
by Binh Nguyen
Full legal name:
Dai Thai Binh Nguyen (everyone calls me 'Binh')
City, Country:
Melbourne, Australia
Profession or Student status:
Mostly student but also do some contract work (computer related, not
necessarily Linux)
Company or School:
University of Melbourne, CAE (Computer Science/Physics/History and
Philosopy of Science/Business).
Your goals in the Fedora Project:
What do you want to write about?
Fork my Linux Dictionary/Computer Dictionary for suitability to
Fedora Project.
What other documentation do you want to see published?
Not sure yet.... I have some things in the works but they're
fairly general....
Do you want to edit for grammar/writing and/or technical accuracy?
Depends on the size of the document. If its reasonable, ie.
smaller than 10 pages than
I'll be more than happy to do a review/edit for grammer/technical details.
Anything else special?
Not at this moment in time.
Historical qualifications:
What other projects or writing have you worked on in the past?
TLDP (Linux Documentation Project), (Author "Linux Dictionary"
and "Linux Filesystem Hierarchy")
TSF (The Shuttleworth Foundation), Computer Dictionary Project
(Author/Project Administrator/Development Lead/Commiter "Computer
Dictionary")
Published technical/commentary articles at linmagau.org,
desktoplinux.com, newsforge.com, linuxtoday.com, linux.org,
pclinuxonline.com, tuxreports.com, etc....
Sourceforge, SpeechSuite (Project Administrator/Development Lead
"uses speech technology to allow interfacing with the Linux CLI;
currently in second stage of evolution, see homepage for details)
What level and type of computer skills do you have?
Fairly competant, can write/program/dabble in hardware, etc....
What other skills do you have that might be applicable? User
interface design, other
so-called soft skills (people skills), programming, etc.
Experience in:
- User Interface Design
- Programming
(C/C++/Java/Prolog/Haskell/x86Assembly/PHP/HTML/XML/BASH/SQL/etc....)
- Recently been playing around with speech and home control
technology (see homepage)
What makes you an excellent match for the project?
I get a kick out of producing high quality pieces of technical work. :)
Binh. (Homepage, http://www.geocities.com/linuxfilesystem/)
[binh@nx5000 ~]$ gpg --fingerprint 50618576
pub 1024D/50618576 2005-05-12 Binh Nguyen (Fedora)
<linuxfilesystem(a)yahoo.com.au>
Key fingerprint = 9C9D D2BE 0A5C 248B 7085 A6C0 F2BE 264B 5061 8576
sub 1024g/C9CCADC5 2005-05-12
18 years, 12 months
Self-Introduction: Max Kanat-Alexander
by Max Kanat-Alexander
/me thinks "Hrm... I've been writing the FAQ since the day FC1 was
released. :-) Maybe I should do one of those self-introduction things on
some list, someday..." :-D
I also figured that maybe it was time to sign up for the fedora-docs-
list. :-) So, happy coincidence, both of these thoughts happened
simultaneously.
Personal Details
----------------
Full legal name: Maxwell Kanat-Alexander
City, Country: San Jose, CA
Profession: Founder & Computer Guy
Company: Everything Solved
I'm also the Release Manager of Bugzilla, as well as being one of its
primary contributors.
Fedora-Docs and Me
------------------
+ Your goals in the Fedora Project:
Be nice. Help out. Have fun. :-)
+ What do you want to write about?
Trogdor. And love.
However, failing that, I'll write the uFAQ. :-)
And maybe somebody could coax me into writing some other stuff, some
day... who knows. :-)
+ What other documentation do you want to see published?
Well, I'd like to expand my Fedora Basics FAQ a bit, here and
there. :-)
+ Do you want to edit for grammar/writing and/or technical accuracy?
Well, I certainly *could*... it might take waving a dead fish in my
face, though. :-)
No, but seriously -- if it's ever like, down to the last minute, and
you desperately need an editor, I'll do it. I'm quite good at it. :-)
+ Anything else special?
I'm mostly just here to provide witty comments and insight if I have
something to say. And maybe I'll get caught up in something interesting
and contribute a bit. :-)
Historical Qualifications
-------------------------
+ What other projects or writing have you worked on in the past?
Well, http://www.fedorafaq.org/ for one. :-)
I also wrote a lot of the Kerio (where I used to work) Knowledge
Base, and some Bugzilla documentation here and there.
Oh, and I wrote a 50-page training manual for Kerio, too.
And finally (in my never-ending string of paragraphs with obviously
creative and unique transitions like "and" and "also") I'm an excellent
songwriter. I'm not sure how relevant that is, though. :-) Unless you
want a Fedora Theme Song.
+ What level and type of computer skills do you have?
Amazing.
+ What other skills do you have that might be applicable? User interface
design, other so-called soft skills (people skills), programming, etc.
I am really, really good at talking to people. I'm also really good
at explaining how things work.
I'm also particularly good at taking very busted, messy processes or
code and making them shine in the morning light.
+ What makes you an excellent match for the project?
Me and the project have been going steady for about two years, now.
I think we might get engaged.
GPG KEYID and fingerprint:
[maxka@localhost ~]$ gpg --fingerprint A1093CAE
pub 1024D/A1093CAE 2000-05-23 Max Kanat-Alexander <mkanat(a)bugzilla.org>
Key fingerprint = E119 9240 601C 389A 9FF0 3DE6 68BD 83FD A109 3CAE
uid Maxwell Kanat-Alexander (Primary email starting in Sept. 2003) <maxka(a)myrealbox.com>
uid Max Kanat-Alexander <max_list(a)fedorafaq.org>
sub 1024g/8D25F5F0 2000-05-23
Note that that doesn't include any of my actual personal email
addresses. :-) Just use this one. :-)
-Max
--
http://www.everythingsolved.com/
Fedora is definitely part of the "everything" in Everything Solved.
19 years
New CVS Layout Tips And Techniques
by Tommy Reynolds
Greetings, Folks!
To make life simpler, we have reorganized the CVS setup for Fedora
Docs. Previously, there was one big module called "fedora-docs".
You checked that out of CVS and you had the all the documents from
the entire project. While you could check out just the part you were
interested in, doing so was clumsy. Adding a new document was
equally awkward.
With the CVS changes now in place, each document forms its own CVS
module and can be checked out individually. Everything that used to
be in the "fedora-docs/" directory is now a top-level module. The
"fedora-docs/" directory is no more; it is an ex-directory; it is
pining for the fjords ;-) Sorry.
1) To see which modules exist (assuming that your $CVSROOT
environment variable is properly set):
$ cvs co -c
2) How do you access an existing document?
First, create a working directory. A "fedora-docs/" holding
directory isn't created automatically as before, so make:
a) yourself a playpen; and then
b) get the overhead doc modules; and then
c) get or create the document you want.
Here is how it goes together:
$ mkdir my-docs-dir
$ cd my-docs-dir
$ cvs co docs-setup
$ cvs co example-tutorial
Note that the "docs-setup" actually gets four modules for you:
"common", "css", "stylesheet-images", and "xsl". You need these for
any document you view or create.
Since each document you get from CVS can share a single "common/",
"css/", "stylesheet-images/" and "xsl/" directory, you only need to
do this once regardless of how many documents you work on
simultaneously.
3) How do I begin a new document?
Much the same was as you do an existing document. You still need
the "docs-setup" checkout, described in the previous section.
Create a new directory for your new document and away you go. A
good technique is to use an existing document as a model:
$ mkdir my-new-document-sandbox
$ cd my-new-document-sandbox
$ cvs co docs-setup
$ cvs co -d my-doc example-tutorial
$ rm -rf my-doc/CVS
Be sure to remove the CVS directory from your new document's
working area ("my-doc/CVS" in our example) because your
document has not been added to the Fedora CVS system yet.
4) How do I get my document into the Fedora CVS system?
Sign up for CVS access!
If you have followed the instructions above, you can add your
document to the Fedora CVS easily. Rename your working directory,
just to be safe, import your document into CVS, and the check out
the "official" verion of your document.
NOTE: take care that you do not try to import a directory named
"CVS"! Your new document should not have *any* CVS
directories before your import is finished.
Continuing our previous example:
$ mv my-doc my-doc-orig
$ cd my-doc-orig
$ cvs import my-doc <my-name> "initial"
$ cd ..
$ cvs co my-doc
Notice that we renamed the working copy to "my-doc-orig", and
then imported that using the real name of "my-doc": this is
the actual module name for your document. Compare its contents with
that of your original "my-doc-orig" directory to ensure its
correctness. Feel free to delete your "my-doc-orig"
directory whenever you wish or keep it forever - your choice.
The Fedora CVS administrator will add an entry into the official
modules listing for you, so you should be see your new document
in the "cvs co -c" listing very soon.
5) Single-Point Updates
A document setup consists of two CVS entities: the "docs-setup"
group and the specific document tree. For example, checking out
the example tutorial:
$ mkdir a-new-world
$ cd a-new-world
$ cvs co docs-setup
$ cvs co example-tutorial
Now, look at the working directory:
$ ls -CF
common/ css/ example-tutorial/ stylesheet-images/ xsl/
That makes 5 separate CVS objects to keep updated. The
directories created by the docs-setup form the infrastructure used
by your document. If you want to keep everything updated, you
could do this:
$ cvs update *
in the "a-new-world/" top-level directory. You can also update
your working document from within its directory, as usual:
$ cd example-tutorial
$ cvs update
6) I already have documents checked out using the old setup. Now
what?
Congratulations on being a current FDP activist!
You have two choices, depending on your confidence:
A) Keep what you have.
Edit each "CVS/Repository" file in your local hierarchy to
remove the "fedora-docs/" prefix from the pathname you find
there. For example:
$ cd example-tutorial
$ cat CVS/Repository
fedora-docs/example-tutorial
$ vi CVS/Repository
$ cat CVS/Repository
example-tutorial
B) Punt and do a fresh checkout. Shhh, we won't tell!
Please enjoy your stay here in Fedora Docs CVS land.
19 years
release notes beats
by Karsten Wade
We have an important job in producing the release notes for Fedora Core.
My idea for doing this is to breakdown the relnotes into journalistic
beats.
In journalism, a beat is a certain area that a writer is in charge of
writing about. For example, the local City Council would be a beat.
The writer in charge of that beat would attend the Council meetings,
meet with the members of the Council, research the issues, and write
about the Council with all the background necessary. This writer
becomes associated with the City Council beat.
Doing this with the release notes makes it possible for a volunteer
group to manage a complex task. If we think of the relnotes like a
newspaper, then each beat reporter is only responsible for writing one
or two columns to get the issue out the door. That is a much easier
task than writing the entire newspaper yourself.
Here are the categories that I have come up with so far.
* Kernel
* Desktop
* Printing
* Server Configuration Tools
* File Systems
* File Servers
* Web Servers
* GCC/Development Tools
* Security
* Java
* System Daemons (cron, etc.)
* Sound and Video
* X Window System (xorg)
* Status of all Packages
What is missing or should be changed about these? Are these attractive
beats that will give you the chance to write about what you are
interested in? Is there a developer team you want to be closely involved
with? Is there a beat that connects with the work that you currently do
or want to do? Should some of these be handled by a beat team?
This is idea is fairly simple, which is the key to its success. If you
are interested in covering one or more beats, please choose your
favorites and let's get this started.
For more of an overview of the process, including ideas for engaging and
interacting with developers, this Wiki page is the current work-in-
progress:
http://www.fedoraproject.org/wiki/DocsProject/ReleaseNotes/Process
- Karsten
--
Karsten Wade, RHCE * Sr. Tech Writer * http://people.redhat.com/kwade/
gpg fingerprint: 2680 DBFD D968 3141 0115 5F1B D992 0E06 AD0E 0C41
Red Hat SELinux Guide
http://www.redhat.com/docs/manuals/enterprise/RHEL-4-Manual/selinux-guide/
19 years
