interesting test

[seth vidal]

On Mon, 2011-07-25 at 13:00 -0700, Toshio Kuratomi wrote:
> On Mon, Jul 25, 2011 at 12:43:28PM -0400, seth vidal wrote:
> > On Mon, 2011-07-25 at 12:31 -0400, Ian Weller wrote:
> > > On Mon, Jul 25, 2011 at 12:24:09PM -0400, seth vidal wrote:
> > > > I've thought a bit about the SoPs and I've been wondering - do we want
> > > > to move them OUT of the wiki and onto infra.fp.o?
> > > 
> > > Or have a cron job that exports them from the wiki and into static pages
> > > on infra.fp.o, instead of moving them?
> > 
> > It still means editing them on the wiki which, imo, is onerous and
> > overkill for what they are. That might just be me, though, but I suspect
> > it isn't. Wiki editing is slow and cumbersome, I've found and a brief
> > interview with a few others in sysadmin-* bears out my suspicion..
> > 
> > Here's what I was thinking, actually:
> > 
> > infra-docs git repo on /git on infra.fp.o
> > 
> > docs exported on commit/push to infra.fp.o/infradocs/ or some such dir
> > 
> > maybe in markdown or rst - but probably just plain text to start with.
> > 
> > The folks who are most likely to write an SoP are going to be comfy with
> > a text editor, I suspect.
> > 
> > It means if someone goes through and mauls the wiki we don't end up with
> > broken docs in our DR location on infra.fp.o.
> > 
> > It also gives us an opportunity to sift through all of our docs in the
> > transition and dump out the ones that don't matter anymore or just
> > aren't accurate.
> > 
> > It would be simple to redirect all SoPs over to that site so no one gets
> > lost.
> > 
> > In general I like the idea of infra.fp.o being the one place we need to
> > recover to bring everything else back up and to know how to bring
> > everything back up.
> > 
> I think the biggest benefits of the wiki are a table of contents (Where on
> the ISOP:PKGDB page do I find something about removing a package?) and
> hyperlinks.  (I'm making a new release; what do I have to do in pkgdb,
> mirrormanger, and bodhi?).  We could do something simple like learn just
> enough rst to be able to have headings and anchors then generate static html
> from that using sphinx.  That would give us static html with table of
> contents and hyperlinks for normal use and the rst text both for editing and
> when we need to read them using less during recovery.
> 

Or, alternatively, just generate an index based on a simple 'first line
of file' mechanism. Most/all is trivial.

I guess I really think I'm more likely to read the files/docs using less
from a prompt.

it means I can use grep to look for things, too.

-sv