CVS Access to our own maintained docs?
by Gavin Henry
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/
19 years
Re: [RFC] Docs Self-Introduction
by Rahul Sundaram
--- 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
19 years
Re: Bug 129957 Submitted for Editing
by Rahul Sundaram
--- 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/
19 years
Re: review of hardening guide
by Rahul Sundaram
--- "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/
19 years
Bug 129957 – Submitted for Editing
by tuxxer
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
19 years
Release Notes translation
by Ronny Buchmann
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.
19 years
Re: PDF generation: xmlroff
by Rahul Sundaram
--- 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/
19 years
FC3 Install Type Packages list
by tuxxer
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
19 years
[RFC] relnotes process
by Karsten Wade
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/
19 years