docs March 2005

docs@lists.fedoraproject.org

21 participants
34 discussions

CVS Access to our own maintained docs?
by Gavin Henry 31 Mar '05

31 Mar '05

Dear Guys, Has there been any progress on this? Our company has CVS access to the packages we maintain on Fedora Extras, will similiar be available to the docs project? -- Kind Regards, Gavin Henry. Managing Director. T +44 (0) 1224 279484 M +44 (0) 7930 323266 F +44 (0) 1224 742001 E ghenry(a)suretecsystems.com Open Source. Open Solutions(tm). http://www.suretecsystems.com/

2 1

Re: [RFC] Docs Self-Introduction
by Rahul Sundaram 31 Mar '05

31 Mar '05

--- Karsten Wade <kwade(a)redhat.com> wrote: > On Wed, 2005-03-30 at 21:18 -0800, Rahul Sundaram > wrote: > > Hi > > > > > * I hope the gpg key isn't a bad hurdle for > writers > > > and editors who are > > > new to open source projects. > > > > It wouldnt be if the process of gpg key generation > is > > documented or an external link is provided on the > > exact steps including the specific path where the > key > > is stored > > What?!? Don't make them google for it, like I have > to every time? > you had to do it. now wouldnt be wonderful not to have everyone else do it just because you did :-) Regards Rahul Sundaram __________________________________ Do you Yahoo!? Yahoo! Mail - You care about security. So do we. http://promotions.yahoo.com/new_mail

1 0

Re: Bug 129957 Submitted for Editing
by Rahul Sundaram 31 Mar '05

31 Mar '05

--- tuxxer <tuxxer(a)cox.net> wrote: > Bugzilla Bug 129957 �� Fedora Core 2 Hardening > Tutorial Request > > Hi all. I've finally got all the content I think I > can put in this > thing in there. It is possible that I've left some > things out, but I > think I've covered most of the basics, which was the > original goal. I > would like to see if this could be evolved into a > comprehensive security > guide that would include a discussion of SELinux, > 3rd party utilities > (that should probably be part of the distro ;-) - > like Firestarter. I believe the firestarter developer uses fedora. You can suggest that the upstream developers propose it for inclusion in fedora extras, do it yourself or find a volunteer to do it Regards Rahul Sundaram __________________________________ Do you Yahoo!? Yahoo! Small Business - Try our new resources site! http://smallbusiness.yahoo.com/resources/

2 1

Re: review of hardening guide
by Rahul Sundaram 31 Mar '05

31 Mar '05

--- "Paul W. Frields" <stickster(a)gmail.com> wrote: > On Wed, 2005-03-30 at 22:17 -0800, Rahul Sundaram > wrote: > > http://members.cox.net/tuxxer/gui-update.html > > > > afaik I know yum is the recommended command line > > program to use instead of up2date in fedora. if > you > > have sections on both yum and up2date you probably > > need to explain the differences too which I would > > consider out of scope for this article > > Since the section is about doing GUI updates, > up2date is the right > utility. The up2date utility is still maintained for > Fedora by Adrian > Likins, and works well. The following section in the > tutorial talks > about using yum as a CLI update program, so I'm a > little confused about > your last sentence there. in fedora it seems yum is the preferred method of doing updates. my point was that its better to suggest a recommended method and stick to it rather than point users to multiple tools which are seemingly redudant Regards Rahul Sundaram __________________________________ Do you Yahoo!? Yahoo! Small Business - Try our new resources site! http://smallbusiness.yahoo.com/resources/

1 0

[RFC] Docs Self-Introduction
by Karsten Wade 31 Mar '05

31 Mar '05

We haven't had a formal docs self-introduction requirement, or even a page saying how. Now we do: http://fedoraproject.org/wiki/DocsProject_2fSelfIntroduction Thoughts? Mine are: * I like the idea of the self-intro. * I hope the gpg key isn't a bad hurdle for writers and editors who are new to open source projects. * The self-intros I've read often show quite a bit about the person who wrote it, so I think it has some value outside of being purely informative. - 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/

2 1

Bug 129957 – Submitted for Editing
by tuxxer 31 Mar '05

31 Mar '05

Bugzilla Bug 129957 – Fedora Core 2 Hardening Tutorial Request Hi all. I've finally got all the content I think I can put in this thing in there. It is possible that I've left some things out, but I think I've covered most of the basics, which was the original goal. I would like to see if this could be evolved into a comprehensive security guide that would include a discussion of SELinux, 3rd party utilities (that should probably be part of the distro ;-) - like Firestarter. But then, I'm daydreaming again. The preview site has been updated. You can check it out at http://members.cox.net/tuxxer , and the XML has been uploaded to http://members.cox.net/tuxxer/fedora-hardening-guide-whole-en.xml , in addition to being attached to the bug. Please let me know of anything (comments, errors, suggestions, etc.). Thanks, -Charlie -- -tuxxer gpg: 57EB F948 76AE 25BC E340 EFA9 FAF6 E1AC F1E1 1EA1

1 0

Release Notes translation
by Ronny Buchmann 30 Mar '05

30 Mar '05

Hi, since the Release Notes are now hosted in the wiki it shouldn't be a problem to have translations there too. What do you think? Remembering FC3 release there were some translators (including me) wanting to do release notes translation. -- http://LinuxWiki.org/RonnyBuchmann PS: Who maintains the wiki? An update to MoinMoin 1.3 would be really helpful in terms of multiple language support. PS#2: Can someone please add me to the EditGroup.

1 0

Re: PDF generation: xmlroff
by Rahul Sundaram 30 Mar '05

30 Mar '05

--- Tim Waugh <twaugh(a)redhat.com> wrote: > Recently I've been taking a look at how far along > the xmlroff project > is (http://sourceforge.net/projects/xmlroff) and > whether it can meet > the needs of the Fedora Project documentation yet. i have been hanging on the LDP lists as a volunteer and reviewer for quite sometime and they do manage to generate PDF's. How about getting in touch with the person responsible(Greg Ferguson, ldp(a)LDP_NO_SPAM.fergusontechgroup.com) and try and resolve the problem that you are having currently Regards Rahul Sundaram __________________________________ Do you Yahoo!? Yahoo! Small Business - Try our new resources site! http://smallbusiness.yahoo.com/resources/

1 0

FC3 Install Type Packages list
by tuxxer 28 Mar '05

28 Mar '05

Hi all, I'm putting the finishing touches on the Security Overview before posting the XML to the bug for editing. I'd like to add an Appendix that has the default package listing of each type of install. Does anyone have a listing like this? Or know where I can find one? If so, this'll save me the trouble of reloading my box several times. ;-) Thanks, Charlie -- -tuxxer gpg: 57EB F948 76AE 25BC E340 EFA9 FAF6 E1AC F1E1 1EA1

2 2

[RFC] relnotes process
by Karsten Wade 17 Mar '05

17 Mar '05

Here are the organization of some ideas generated during an impromptu discussion on #fedora-docs. The ideas here make doing the release notes fun, manageable, and a good opportunity for writers and editors who want a closer interaction with developers and the Fedora release process. # Suppositions The Fedora Core release notes (relnotes) are a massive undertaking for a single individual to do manually. Even as a group effort, the collection and sorting for useful bits of information (content) to document is a large undertaking. For the release notes and all documentation to be meaningful and useful, the developers need to embrace them as part of their process. Process additions for developers need to minimally interrupt an already working and complex workflow. Places in the workflow we can capture useful content to document include: 1. CVS check-in comments 2. bugzilla for all packages 3. easy-to-send-to email address # The Pieces There are two major parts: the in-flow of content from developers and the community, and the churning of that content into a release notes. We'll call them the gathering and writing parts. ## Gathering the content For CVS check-in, we could use unique keywords in the comments such as DOXEN or RELNOTES, and a longer description explaining the change. Similar for changes to packages overall. Then we have to work with release engineering (rel-eng) to automate the extraction of that content. Doc teams can then work on the content throughout the development process. For example, a weekly script extracts the useful pieces and generates populated bugzilla reports for each special KEYWORD by team type. This requires some extra thought on the part of developers, and we'll provide them a nicely documented process. Bugzilla could take advantage of existing or new closing types or flags that mark a bug as worthy of a DOCUMENT note. An email alias can start as an alias to a group doing the relnotes. It can later be channeled into a script to do interesting things, such as creating bugzilla entries. We need a process doc that tells developers how to identify something that is worth documenting. This is a whole topic in itself. This might be driven by the scope of a specific document, or by general guidelines of the various audiences we write for. ## Writing the content The general idea here is to model the success that software projects have. Modularize the release notes, making individuals or small groups responsible for a piece of the relnotes. Work goes on in parallel, and at certain milestones (test, release candidate, release), the modules form like Voltron ... that is, connect together and receive a group edit/check. These relnote module groups can interact more closely with the developers related to their content. A group of developers knows who is going to be asking and answering the documentation needs for a subject area. The doc writers and editors can become subject matter experts for their area. For example, I could be accountable for gathering and writing the SELinux release notes section, and I use the same set of relationships to write the Fedora SELinux FAQ, and ultimately the Red Hat SELinux Guide. Everyone knows who to bring SELinux documentation questions to. I know which kernel, userspace, policy, and desktop people to go to for information throughout the release cycle, which mailing lists to read and so forth. Here are some ideas for modules/areas of expertise. These would map directly to different parts of the relnotes. We work on separate <section>s as separate files and merge them with one parent XML file. * kernel * installer * hardware/drivers * packages (added, moved to extra, deprecated, AKA "package watch") * server groups * Apache * Samba * ... * Misc daemons * security groups * SELinux * ExecShield/PIE * ... * networking Each module can attract an individual or team, depending on the complexity. For writers/editors, this gives a chance to work more closely with developers of material you are interested in. You can more easily spin off Fedora docs or your own, outside written works from this relationship. Personally, if I wanted to write a book about managing Samba for Fedora Core, it would be advantageous if I were the release notes maintainer for Samba in Fedora, eh? ;-) ## Random thoughts Can we rethink the release notes? Can these be more useful and accessible for the general user? Or must one have some idea of Linux, hardware, etc. in order to need the relnotes? ## 30 ## -- Karsten Wade, RHCE * Sr. Tech Writer * http://people.redhat.com/kwade/ gpg fingerprint: 2680 DBFD D968 3141 0115 5F1B D992 0E06 AD0E 0C41 Learn, Network and Experience Open Source. Red Hat Summit, New Orleans 2005 http://www.redhat.com/promo/summit/

3 3

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

docs March 2005