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
> > > 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
> 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.