On Sat, 2008-01-05 at 16:12 +0100, Bart Couvreur wrote:
Op zaterdag 05-01-2008 om 09:56 uur [tijdzone -0500], schreef Paul
W.
Frields:
[snip]
> This is my fault -- I only made a F-8 branch for Marc when he started
> working on this. I haven't seen many commits lately, though -- there
> are some changes to a couple paragraphs that mention graphical tools,
> though, and some changes to the Fedora release numbers. Marc, did you
> find when you checked that everything else in the FAQ was still
> applicable?
>
> I was hoping that more of Dan Walsh's material from the wiki[1] would be
> prominently available in official docs, but do we want to:
>
> 1. ...incoprorate Walsh's work in the FAQ?
+ 1 but a lot of his work
relates to how to achieve things where as the
faq gives brief examples but not to detailed.
Yes, this should definitely happen. There's a lot of stuff Walsh's
written which explains most of SELinux.
> 2. ...roll the FAQ into the Admin Guide and add Walsh's work there?
> 3. ...keep them separate?
Keep it separate I think there should be a mention with a link from the
admin guide to the FAQ.
I would like to keep them separate, it would bloat the AG too much.
Once
you start of with SELinux the amount of content gets tripled. And we
don't really want people searching SELinux stuff to go through the whole
AG to find what they need as SELinux sometimes affects a whole portion
of the system.
> 4. ...[other]?
Upgrade the FAQ to a more formal Guide? This includes a lot of intro,
and why is SELinux what it is, but that would mostly be a rephrasing /
styling of the content out there on the different wiki's, blogs, ...
Upgrade the FAQ to a formal guide seems like the best way to go.
I checked all the links and rearranged the words. I couldn't add much
of Walsh's stuff into it because it didn't seem to fit. There was a lot
of use case scenario's in Walsh's posts and while thats great for a
guide in a simple FAQ it would not explain it sufficiently it seemed so
I didn't add it into there.
The details in the FAQ still seem to work. I don't modify selinux to
much since I don't understand the scripting of it, I left those bits
alone since I couldn't verify or change anything in the guides.
Cheers,
Marc
P.S. If we are writing it as a guide can we talk to Walsh to get some
ideas on use cases?