Please do not reply directly to this email. All additional
comments should be made in the comments box of this bug report.
Summary: lack of documentation on restoring from bare-metal (UUID
Product: Fedora Documentation
Description of problem:
There is a lack of documentation on restoring a system from bare metal. I have
found (see reference) that restore the root ("/") is not as simple as as just
executing the restore command when running in rescue mode.
With the current emphasis being place on use of UUIDs in both Fedora and RHEL,
the whole business of UUIDs need to be better documented.
Version-Release number of selected component (if applicable):
Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.
I just realised that I've never formally introduced myself.
So here goes, I'm Nigel Jones, a proud New Zealander that has been
meaning to do a little bit of documentation work for AGES. I've
recently done 6 months teaching IT to domestic and international
students, and really documentation is the best way to help students.
I'm quite technically competent (I passed RHCT with 100%) so I'm
definitely eyeing up getting the Administration guide out the door.
Recently I'm known for my work on the wiki and helping people with
Mediawiki syntax (who've thunk it?).
Anything else, just ask (feel free to prove to Murray that I'm not
I started copying some content to make an SVN tutorial:
I am hopeless with Mediawiki, so apologies for the layout. I will try
to clean it up on the weekend, and include some branching bits.
I do not know how this works with fedora hosted projects, so I left
the URLs generic and unhelpful.
Hope that helps,
pub 1024D/81B3FDEB 2007-09-19 [expires: 2008-09-18]
Key fingerprint = 4ED9 9907 5BF0 4132 2B46 20D1 C0C6 362D 81B3 FDEB
Murray McAllister (Fedora Docs Project / mdious) <murray.mcallister(a)gmail.com>
sub 2048g/B04CFA0C 2007-09-19 [expires: 2008-09-18]
Pretty version at:
12:05 < quaid> <meeting>
12:05 -!- quaid changed the topic of #fedora-meeting to: Fedora Docs - roll call, greets
12:05 * quaid is here :)
12:05 * ianweller
12:06 * jsmith is here
12:06 * Sparks here
12:06 -!- abadger19991 [n=abadger1(a)126.96.36.199] has joined #fedora-meeting
12:06 < quaid> agenda is https://fedoraproject.org/wiki/DocsProject/SteeringCommittee/Meetings#Age...
12:06 -!- abadger1999 [n=abadger1(a)188.8.131.52] has quit ["Leaving."]
12:06 < G> I'm here :)
12:06 * ke4qqq is here
12:07 -!- JSchmitt [n=s4504kr@fedora/JSchmitt] has quit ["Konversation terminated!"]
12:07 -!- quaid changed the topic of #fedora-meeting to: Fedora Docs - Wiki namespaces discussion
12:07 < stickster> quaid: I just added something to that agenda
12:07 < quaid> ok
12:07 < quaid> http://www.redhat.com/archives/fedora-docs-list/2008-July/msg00092.html
12:07 < quaid> that is the RFC currently under discussion
12:08 < G> quaid: might be something to pull out my original e-mail to docs/websites too
12:08 * ianweller wonders whether we should say "Documentation Project" or "Docs Project" now that we're moving to spaces/full names
12:08 -!- abadger1999 [n=abadger1(a)184.108.40.206] has joined #fedora-meeting
12:08 -!- rvokal [n=radek(a)ip-89-102-32-70.karneval.cz] has joined #fedora-meeting
12:09 < G> quaid: http://www.redhat.com/archives/fedora-docs-list/2008-July/msg00015.html - the original namespace discussion
12:09 * quaid was replying onlist too
12:09 < quaid> ianweller: people say Docs, like it or not, so I gave up on that a bit ago; but worth standardizing, yes :)
12:10 * ianweller wonders how google-friendly that is
12:10 < quaid> G: yes, but that is a bit farther down in the agenda
12:10 -!- mether [n=sundaram@nat/redhat-in/x-6f9c178ba5415a81] has joined #fedora-meeting
12:10 < G> quaid: errr the 'namespaces' got me, oop :0
12:10 < quaid> ianweller: hard to say; techie people seem to always use 'docs' but documenters prefer 'documentation'
12:11 < quaid> G: yep, sorry :)
12:11 -!- quaid changed the topic of #fedora-meeting to: Fedora Docs - wiki page naming discussion
12:11 < quaid> that's what I meant :)
12:11 * ianweller googles for "fedora documentation" and sees if he gets DocsProject.
12:11 < quaid> ok, so are there any questions about the RFC?
12:12 < ianweller> we know why, and we know where to move things. how to do it though?
12:12 < quaid> one thing before that
12:13 < quaid> is everyone comfortable with Docs making this decision and putting it forward as done to the contributor community?
12:13 < Sparks> +1
12:13 < quaid> v. sending an RFC to f-devel-l :D
12:13 < ianweller> no. we have an RFC, we need a policy that contributors can follow, i think
12:13 < G> quaid: I disagree with mass transclusion btw
12:13 < G> (of content pages)
12:13 < ke4qqq> quaid: +1
12:13 < ianweller> i don't think what we have now is in policy state
12:13 < quaid> G: you mean, my idea of building a guide is mass transclusion?
12:13 < quaid> ianweller: right, but ...
12:14 < ianweller> and, to the new user, i think it's a bit confusing
12:14 < quaid> the biggest point of contention is going to be the stupid naming
12:14 < quaid> +1 that it is *not* a policy
12:14 < G> quaid: correct
12:14 < quaid> and needs sto be
12:14 < ianweller> that's a good "ok here's how we're *moving* it" page, but we need something that says "this is how the wiki is organized, deal with it"
12:14 < ianweller> yeah
12:14 < quaid> G: is it that much of a performance hit difference?
12:15 < quaid> I thought each section was separate in the db anyway
12:15 < quaid> ianweller: but are you comfortable with us making all that policy and not taking argument about it?
12:15 < ianweller> yes.
12:16 < quaid> I mean, the Packaging Committee has a process to get changes approved; this would be like that, don't just bitch on a mailing list but bring a real proposal.
12:16 < quaid> stickster: how about you?
12:16 < G> quaid: I think the difference is, it can pull an entire page in one query, where as for transclusions it had to keep making queries
12:16 < quaid> G: ok
12:16 < stickster> Sorry, there is a conversation going on here that I am trying to shut out so I can catch up here
12:16 < G> I may be wrong, I havn't had my morning coffee and I'm just running off memory :)
12:17 < quaid> g: it might have been a mis-guided solution to a non-problem; definitely we should set a policy on that, maybe a limit on the # of sections to transclude?
12:17 < quaid> G: ouch, sorry, it _is_ early there
12:17 -!- dwmw2 is now known as dwmw2_gone
12:17 < stickster> quaid: OK, the RFC is to use "real languge" for page titles, and categories to organize pages ?
12:18 < G> quaid: I think the proper solution would be to say: split the document in three bits or so (to avoid it getting too large)
12:18 < ianweller> G: split the document in, say, 20KB bits, so that it's unlikely for pages to go over 32KB?
12:18 < G> "General Policies", "RPM Issues", "Technical Policies" type thing
12:19 < quaid> stickster: ok, here's the question I asked you:
12:19 * ianweller still doesn't know what sort of performance hit transcluding lots of pages takes, and wonders if #mediawiki knows
12:19 < G> ianweller: I dont consider the 32KB rule as a general policy
12:19 * stickster apologizes, too many concurrent inputs :-)
12:19 < quaid> "Are we OK with Docs making the policy for wiki structure, including naming, and pushing it forward as "done until you formally help change it"?"
12:19 < G> the 32KB warning comes from some browsers not been able to cope with it iirc
12:19 < ianweller> G: well, right. so in my mind, anything larger than 32KB is right out
12:20 < quaid> ianweller: but you said Packaging_Guidelines needs to be one page :)
12:20 < G> ianweller: I don't know of any browsers these days that have such a problem
12:20 < stickster> quaid: +1 on that.
12:20 < quaid> stickster: ok! :)
12:20 < stickster> quaid: The day belongs to those who seize it.
12:20 * ianweller is a hypocrite again, damn!
12:20 < quaid> carpe seizem
12:20 * ianweller goes to get more tea
12:20 < quaid> ok, then
12:20 < quaid> just to recap:
12:20 < stickster> ianweller wants to eat his cake and have it too :-D
12:20 < quaid> * we agree we are empowered to do this
12:20 < G> quaid: I disagree with transcluding it, I'd favour logical splitting :)
12:21 * ianweller goes back through his head and rehashes out what he wants
12:21 < quaid> * we need to convert the Help:Wiki_structure to a policy page
12:21 < stickster> G: I think you can really do both at will.
12:21 < stickster> It's kind of a red herring issue.
12:22 < G> (It's currently 52KB so a split in two - General Packaging Guidelines, Technical Packaging Guidelines
12:22 < quaid> ok, that's later in the agnedna :)
12:22 < quaid> let's finish with page naming
12:23 < quaid> Ian's point on list about not splitting the P_G too small is noted/OK
12:23 -!- abadger19991 [n=abadger1(a)220.127.116.11] has quit [No route to host]
12:23 < ianweller> right now we already split P_G into different sections for specific languages, btw
12:23 < quaid> so, on naming
12:24 < quaid> an no Sub/Pages
12:24 < quaid> all happy with that?
12:24 < quaid> I think we need a bit of list discussion, too, fwiw
12:24 < G> I disagree
12:24 < G> I have a technical arguement too that I just remembered
12:24 < ianweller> is the no Sub/Pages a soft limit, meaning we still have Artwork/Join?
12:24 < ianweller> G: mm?
12:24 < quaid> ianweller: not a soft limit IMO
12:25 -!- dstimson [n=dale(a)68-185-24-58.static.mdfd.or.charter.com] has left #fedora-meeting ["Leaving"]
12:25 < ianweller> quaid: same here. /me wants no slashes ;)
12:25 < ianweller> except in non-main namespaces
12:25 < G> Legal have asked us, to make sure Legal/* is read only to everyone but people in the Legal group, Packaging/* is read only to people except in Packaging group, we can't just shut them out
12:25 < quaid> I want to see one or another method, and tightly enforced
12:25 < quaid> G: how do ACLs work?
12:25 < G> I proposed separte namespaces from them at inception but was told "ewww thats ugly"
12:25 -!- Sonar_Guy [n=Who_Know@fedora/sonarguy] has quit ["Leaving"]
12:25 < G> *for them
12:26 < ianweller> G: can we ACL by category?
12:26 * ianweller presumes not
12:26 < G> quaid: Packaging/*
12:26 -!- abadger1999 [n=abadger1(a)18.104.22.168] has quit [No route to host]
12:26 < quaid> G: what about Packaging*
12:26 < quaid> and Legal*
12:26 < G> ianweller: nope, MW doesn't allow that type of call
12:26 < quaid> without the /
12:26 < ianweller> quaid: but then we might run into other issues.
12:26 < G> quaid: I wouldn't be sure, but I'd feel that was an ugly solution
12:26 < quaid> well, sure, if someone wants to write "Legally_thinking_about_open_source" they cannot
12:27 < ianweller> i *personally* think that namespaces could/should/must be used
12:27 < ianweller> for cases such as these
12:27 < quaid> ianweller: you mean
12:27 < quaid> Namespace:s
12:27 < quaid> not Name/Space
12:27 < ianweller> quaid: yes.
12:27 -!- spstarr_work [n=spstarr(a)22.214.171.124] has left #fedora-meeting ["Ex-Chat"]
12:27 < ianweller> i am not sure how people decided that Name/Space meant namespace :/
12:27 < ianweller> (no offense to anyone)
12:28 < quaid> ianweller: ha!
12:28 < G> and you've got to consider that "Packaging:Foo" is going to have the exact same effect as "Packaging/Foo"
12:28 < quaid> ianweller: um, we had that term in general usebefore Mediawiki was born :)
12:28 < ianweller> quaid: oh ok.
12:28 < quaid> G: 'effect'?
12:28 < Sparks> In MW... What's the difference between Docs/Page and Docs:Page?
12:28 < quaid> Sparks: search is in specific namespaces
12:28 < ianweller> Sparks: you can decide to include/exclude certain Namespace:s in search.
12:28 < G> quaid: yuckyness in Category sorts etc iirc
12:28 < quaid> Sparks: we can reset the default, but that doesn't change it for existing users
12:29 < ianweller> G: can't you fix that?
12:29 < ianweller> potentially with wikibot?
12:29 < ke4qqq> quaid: yes but you can change default search
12:29 < quaid> ke4qqq: not for existing users aiui
12:29 < G> quaid: we can change it for existing users
12:29 < quaid> we _are_ going to change it, one time we hope
12:29 < quaid> G: oh, ok
12:29 < G> quaid: I said that during one of the other discussions
12:29 -!- bpepple|lt [n=bpepple|(a)rrcs-70-62-4-107.central.biz.rr.com] has joined #fedora-meeting
12:29 < quaid> G: thx, I forgot
12:29 < G> quaid: but I'd perfer to hold off on that until we get the l10n wikis sorted
12:30 < quaid> here's my thinking then ...
12:30 < quaid> on ACLs
12:30 < quaid> if Legal needs a protected space, move it off the wiki
12:30 < ianweller> quaid: we tried pushing that to them at the beginning too
12:30 < quaid> if Packaging needs a guide that cannot be edited by the masses, move it off the wiki
12:30 < ianweller> since wikis are not made for ACLs.
12:30 < Sparks> quaid: If you start moving people off the wiki then how will anyone know where to look for inforamtion?
12:30 < quaid> Sparks: the wiki is not the sole source of info
12:30 < ianweller> but they certainly did not like that. at all.
12:31 < G> quaid: that in my opinion isn't a good solution
12:31 < quaid> Sparks: docs.fp.o/release-notes for example
12:31 < quaid> ianweller, G why?
12:31 < quaid> oh, they want the ease of a wiki but not have it be a wiki?
12:31 < quaid> get a CMS, I say
12:31 < Sparks> quaid: Yeah, which is one reason why I think people have ahard time finding information
12:31 < ianweller> yes.
12:31 < ianweller> quaid: hehe
12:31 < ianweller> of course!
12:31 < quaid> Sparks: the wiki needs to link to the rest of the world, too' we cannot put all in the wiki, it sucks too much for content management
12:32 < G> quaid: that sort of stuff changes frequently and a wiki is a good way to display such information
12:32 < quaid> G: it actually doesn't change that frequently
12:32 < ianweller> (should we get some people who work on Legal/* and Packaging/* stuff's input?)
12:32 < G> quaid: parts of the Packaging/* area have a bit of turnover I've seen
12:33 * ianweller just had the idea of shoving the packaging guidelines into docbook, in a repo on fedorahosted
12:33 * ianweller notes that that idea is *not* going to be popular
12:33 < quaid> G: if they are active, why cannot they watch the pages like the rest of us do?
12:33 < quaid> ianweller: if they need ACLs, maybe that is the best thing
12:33 < quaid> here
12:33 < ianweller> quaid: i think so.
12:33 < quaid> here's what I'm getting at:
12:33 -!- AndreasR [n=medic(a)ext-32-32.mobile.unibas.ch] has joined #fedora-meeting
12:33 < quaid> we CANNOT make our naming decisions based on these corner cases
12:33 < quaid> that are leftover from previous bad decisions
12:33 < quaid> in the previous wiki.
12:34 < quaid> we CAN make an exception
12:34 < ianweller> agreed.
12:34 < quaid> and allow Legal/ and Packaging/
12:34 < G> I think thats what we need to do really
12:34 < ianweller> (but only for now, imho)
12:34 < quaid> but, G, really, is it worth carrying on that travesty for all pages?
12:34 < G> for now anyway
12:34 < G> quaid: How about this:
12:34 < ianweller> there's a better solution, and we can decide on that with the respective name/space owners later
12:34 < G> * Allow Legal/ Packaging/ as exceptions for now
12:35 < G> * Approve Legal: Packaging: if they want it (but say it's an equally ugly solution) and recommend they incorporate stuff into the websites or documentation
12:35 < ianweller> +1
12:36 < quaid> +1, with the caveat that we can go get spot's input before entirely granting the exception
12:36 < quaid> (since spot is the dude leading both of those sections)
12:36 < ianweller> yes.
12:36 < G> * When the l10n wikis are put in, then change everyones default search to add those namespaces
12:36 < G> (and add the namespace then)
12:37 < ianweller> G: we need to i18n namespaces too, right?
12:37 < quaid> ianweller: it's just l10n, aiui
12:37 < G> no
12:37 < quaid> we use i18n to l10n the pages
12:37 < ianweller> well
12:38 < ianweller> what i mean is
12:38 < ianweller> change the name of the namespace into whatever it is for the respective language
12:38 < ianweller> just keep the same ID numbers in the database at the very least
12:38 < G> for most cases thats done, and it'd be a requirement of the l10n teams to do such a task before the wiki is created
12:38 < ianweller> excellent
12:39 < G> I've already discussed quite a bit of the implementation stuff like this with couf
12:39 < quaid> cool
12:39 < quaid> any more on this naming?
12:40 < quaid> do we think we have consensus here?
12:40 < ianweller> i think we're good.
12:40 < G> quaid: yeah, but we really need to look into the Legal/ Packaging/ stuff a bit more
12:40 < quaid> G: I know you mentally prefer Sub/Page, and I do think many people agree, but the l10n need in the end was a big persuader for me
12:40 < ianweller> then again, it's just the three (four?) of us talking about it, from what i can tell
12:41 < quaid> i.e., Artwork/Join has impedence mismatch with what that page actually is, Join_the_Art_project
12:41 < quaid> ianweller: carpe diem, etc.
12:41 < G> quaid: FreeDistribution is another one that uses ACLs on their subpage
12:41 * ianweller yawns
12:41 < ianweller> ;)
12:41 < G> quaid: it's a case of, I think in most cases subpages look nicer
12:41 < ianweller> G: so should we change your proposal from Legal/* and Packaging/* to whatever happens to be in the HNP ACL at the moment?
12:42 < quaid> wtf is FreeDistribution?
12:42 < G> quaid: the Free CDs folks
12:42 < G> they ACL a couple of the pages
12:42 < quaid> I'd want to go to each group and find out why they need ACLs
12:43 < quaid> well, a couple can be just done manually, right?
12:43 < G> even Infrastructure have ACL'd pages
12:43 < quaid> the exception is where an entire set of content needs ACLs
12:43 -!- alexxed [n=alex@conference/mozilla-summit/x-2b2f748cd8cfed4d] has joined #fedora-meeting
12:43 < G> quaid: correct
12:43 * G would really like to do away with HNP tbh, it's ugly
12:44 * ianweller would like to do away with any extensions we don't actually need (i.e., HNP) ;)
12:44 < G> it's an ugly solution to do something that mediawiki isn't designed for
12:45 < G> quaid: just sent you a /notice, don't know if you'll be able to read it, but if you can it's a list of the current ACLs
12:46 < G> ohhh forgot Licensing too, thats a big chunk
12:47 -!- mether [n=sundaram@nat/redhat-in/x-6f9c178ba5415a81] has quit [Read error: 110 (Connection timed out)]
12:47 -!- paragn [n=paragn@fedora/paragn] has quit [Read error: 110 (Connection timed out)]
12:47 < quaid> yeah, a few Foo/ exceptions is OK
12:48 < ianweller> with the mention that they shouldn't be exceptions, imho.
12:48 < quaid> mainly what I want is the general, open, edit-me content for contributors and users is a flat namespace, easy to know what to name, lots of categories
12:48 < quaid> oh, yeah!
12:48 < quaid> how about we create a bunch of stub category pages?
12:48 -!- paragn [n=paragn@fedora/paragn] has joined #fedora-meeting
12:48 < quaid> Category:Bug_Triage for example
12:48 -!- mether [n=sundaram(a)126.96.36.199] has joined #fedora-meeting
12:48 < ianweller> so, Category:Bug_triaging_stubs?
12:48 < quaid> i.e., at least one for each ProjectName/ we are replacing with the renaming
12:49 < quaid> and advertise that as the category to use instead of the old SubPage/Style
12:49 < G> quaid: in some cases they already have a similar category, it'd be best to send wikibot over them - like I did for the Docs pages and rename them
12:49 < ianweller> i'm not sure if this is relevant right now but how nim-nim has been doing things for fonts is that he's been using the Category: page as the main page for his SIG
12:49 < quaid> G: right, let's do all that
12:49 * quaid adds that to the wiki gardening tasks
12:50 < ianweller> which i recommend against using Category:s as starting points.
12:50 < G> ianweller: that imo isn't using the category page for what it's designed to do
12:50 < ianweller> G: yeah
12:51 < quaid> hmm
12:51 -!- LyosNorezel [n=LyosNore@unaffiliated/lyosnorezel] has left #fedora-meeting 
12:51 < quaid> makes it easy, though :)
12:52 < ianweller> it does, but it's not what we want, i think.
12:52 < ianweller> some projects will want to do that, most won't
12:52 < ianweller> and we need to standardize it
12:52 < quaid> we can recommend against it? or make a rule, not sure
12:52 * ianweller would make it a strong recommendation against.
12:52 < ianweller> if not a rule
12:53 < ianweller> i'd say that's up to you guys to decide
12:53 < quaid> ok, so ...
12:53 < G> agreed,
12:53 < quaid> I think we've covered the top item on the agenda
12:53 < ianweller> in a record time of 53 minutes! :=o
12:53 < ianweller> :-o*
12:54 < ianweller> ;)
12:54 < ianweller> is someone logging/noting what we decided?
12:54 < quaid> ianweller: I like the idea of using the MW style guide as a basis, then noting the variations
12:54 < quaid> similar to what we do with GNOME Docs style guide, etc.
12:54 < quaid> ianweller: I'll take the summary task today :)
12:54 < stickster> heh
12:54 < ianweller> excellent
12:54 < stickster> quaid: Thanks
12:54 < ianweller> imho, people should be familiar with the wikipedia page naming guidelines *first* and then read our specifications
12:55 < ianweller> or, we can take wikipedia's and adapt them appropriately
12:56 < ianweller> quaid: iirc the next item on the agenda was namespace:s? or did we kinda sorta cover that
12:56 * ianweller was thinking maybe we should decide what should be the initial namespaces
12:56 < quaid> ianweller: yeah, we jumped over that, sorry
12:56 < quaid> but I think we can decide that
12:56 < ianweller> heh
12:56 * ianweller notes that Features: would be an important one
12:56 < quaid> hmmm
12:56 < quaid> I wonder if we have a bigger discussion here?>
12:56 < ianweller> we kinda do.
12:56 < quaid> should we worry about a proliferation of namespaces?
12:57 < ianweller> i think we should only approve namespaces if the content will not be considered documenation for end users or contributors
12:57 < G> quaid: It could potentially get too big
12:57 < ianweller> but otherwise, we need a hard rule one way or the other
12:57 < quaid> ianweller: yeah, that was my thinking in general
12:57 < G> ianweller: in that case feature pages fit into that rule
12:57 < ianweller> G: yes, they do
12:58 < ianweller> but, then so do theme proposals from the artwork team.
12:58 < quaid> so, no Features: namespace?
12:58 < G> err I mean, they fit into "documentation for end users or contributors"
12:58 < quaid> G: +1
12:58 < ianweller> how do they do that? i see them more as FESCo organization in my mind
12:58 < quaid> contributors work on them
12:59 < quaid> marketers use them to write from
12:59 < quaid> people read them to know what is coming
12:59 < quaid> etc.
12:59 < G> exactly
12:59 < ianweller> so we're going to just use the concept of putting 'feature' somewhere in the title and categorizing it appropriately as it is now?
13:00 < ianweller> like "Better webcam support feature for F10"
13:00 < ianweller> maybe even s/feature //
13:00 < G> well thats the way the rest of the policy is going, so yes
13:00 < ianweller> ok.
13:00 < quaid> ianweller: John maintains a set of categories
13:00 < ianweller> quaid: i know
13:00 < quaid> that is where to find the list ultimately, not by name
13:00 < ianweller> Category:FeatureF10Proposed or something like that
13:00 -!- abadger1999 [n=abadger1(a)188.8.131.52] has joined #fedora-meeting
13:00 < quaid> we're out of time
13:01 < ianweller> ack
13:01 < G> quaid: so do you want me to add the Meeting: namespace now?
13:01 < quaid> namespaces discussion -- to the list!
13:01 < ianweller> right-o.
13:01 < jsmith> +1
13:01 < ianweller> who should turn Help:Wiki organization (or whatever it was, i don't remember) into a policy?
13:01 < quaid> G: I'll reply to you on list giving people One Last Chance to argue, then we'll do it, sound OK?
13:01 * ianweller could, unless someone else wants to
13:01 < quaid> the last item
13:01 < G> quaid: good idea
13:01 < quaid> that we need to make up a skeleton release announcement
13:02 < quaid> anyone here interested in that task? or push request to the list?
13:02 < ianweller> what do you mean
13:02 < ianweller> "skeleton release announcement"
13:02 < quaid> sorry, for Alpha
13:02 < ianweller> oh ok.
13:02 < quaid> request from releng, basically
13:02 < quaid> I'll own that for now, see if I can find another doer :)
13:03 < quaid> all right, closing and getting out of the channel's way
13:03 < ianweller> ok someone's waiting for us to finish so /me moves to end meeting
13:03 < ianweller> yeah.
13:03 < quaid> </meeting>
We've been discussing adding these namespaces to the wiki:
Meeting: is for meeting logs and the like, which often clutter up the
main searches. This namespace puts the meeting logs in a separate area,
where naming and categories can further identify. E.g.:
Archive: is for old content that we don't want to destroy/replace, but
which is cluttering and confusing search results. For example, content
related to an old, unsupported release. E.g.:
Any final thoughts or objections? Raise them here or on the original
Thanks - Karsten
Karsten Wade, Sr. Developer Community Mgr.
Dev Fu : http://developer.redhatmagazine.com
Fedora : http://quaid.fedorapeople.org
gpg key : AD0E0C41
-------- Forwarded Message --------
> From: Paul W. Frields <stickster(a)gmail.com>
> To: fedora-devel-announce(a)redhat.com, fedora-advisory-board
> Subject: Release Planning Recap :: 2008-07-30, UTC 1700
> Date: Wed, 30 Jul 2008 18:43:13 +0000
> = Release planning meeting, 2008-07-30 =
> === Docs ===
> * Alpha and Beta release notes are a one-sheet on the wiki
> ** Living document, can change after release day
> ** QA, Desktop, and RelEng have done a great job of adding some
> important content
> ** Priority is to let testers know what you want them to do with the
> '''DEBUGGING:''' We need a list of pre-approved URLs for release
> * Docs can handle the majority of the text for the release announcement
> email, and check URLs, so releng can concentrate on sending it out when
> * Release notes production is hopefully going to change with F10 to use
> an in-distro tool, publican, to build
I'm holding on a RH press blog entry that will also tout the Alpha
release for a wider community. If we can get this list of URLs together
-- and would it make sense for that to live somewhere longer-term? -- I
want to use it in this blog entry too.
Paul W. Frields
gpg fingerprint: 3DA6 A0AC 6D58 FEC4 0233 5906 ACDB C937 BD11 3717
http://paul.frields.org/ - - http://pfrields.fedorapeople.org/irc.freenode.net: stickster @ #fedora-docs, #fedora-devel, #fredlug
This page has been edited to show a final structure for how pages are
The background discussion on why is found here:
In the end, I was swayed by nim (Nicolas Mailhot) and Ian Weller over
two items. The first part is the global, multi-lingual audience. Here
is a relevant section from the discussion:
Say outloud these two page titles: "Docs Project meetings" and
"Meetings of the Docs Project". They are both accurate and sound
fine, for native language speakers. In English, it is more
likely that the shorter, more declarative form ("Docs Project
meetings") is going to be used; many would call that version
"more natural", perhaps because of the English speaker's habit
of removing articles (the) and prepositions (of).
* One way to explain why to use this style of naming, rather
than calling it "natural language forms", say they are "easier
to understand for non-native readers" and "easier to translate."
* Another good argument is that having pages with intrinsically
accurate titles means they sort properly on the category page.
As you point out, all the meetings then fall under "Meetings of
Foo-20080630" and sort chronologically etc.
* Agree --Ian Weller 04:28, 2 July 2008 (UTC)
The second part is in how I think we can use MediaWiki.
The wiki should guide people in how to do something -- learn more, do
more, play more, etc.
To make such guides with a Sub/Page/Structure forces content to exist in
only one ''guide space'', fixed by name. The only way to change it is
to change all the page names and update incoming links.
In WM, the categories are the guide spaces. We'll use
[[Category:Packaging Guidelines]] on every page of the current
PackagingGuidelines/ guide space, then rename each page to something
unique to that page.
* '''old''' PackagingGuidelines#Beware_of_Rpath
* '''new''' Beware_of_rpath_in_packaging
Then a visit to [[Category:Packaging Guidelines]] shows the pages, all
in alphabetical order, all stating what they are about.
To recreate the layout of the current PackagingGuidelines page, we
construct a page that either links to or transcludes all the particular
pages in the order you wish. Using a transclude allows the page to be
reorganized and autocreate the ToC, so is the preferable method.
As an example of the mess we currently have,
https://fedoraproject.org/wiki/Packaging currently redirects here:
Anything confusing on that page?
This new method is designed to solve ugly pages like that. :)
Karsten Wade, Sr. Developer Community Mgr.
Dev Fu : http://developer.redhatmagazine.com
Fedora : http://quaid.fedorapeople.org
gpg key : AD0E0C41
Quick note to introduce myself and volunteer for the RelNotes Filesystems Beat
I am a sysadmin for a consulting company based in South Carolina,
where about 25% of my job deals with creating documentation. I've been
a Fedora Ambassador for several years and contributed a few other
I currently maintain the SecAdvisories Beat for FWN.
As for writing I have managed to fool a few magazine editors into
letting me write a few articles over the years. In a OSS project I was
involved in around 4 years ago I dealt with DocBook, but I am sure my
skills are pretty rusty from lack of use, but hopefully I can ramp
back up pretty quickly.
If no one else has stepped forward to handle the Filesystems Beat I'll do so.
my name is Kai Heimann and I live in Townsville, Australia. I am a
student at James Cook University, studying a Bachelor of Information
Technology, currently in my second year.
I would like to get actively involved in the Fedora Project as I use
Fedora and am always recommending it to people. I believe that OSS is a
solution for most people out there, but it does take the involvement of
the community to make sure that it keeps growing, changing and
improving. My goal in the Fedora Project is to try and aid others in
becoming more adept at using Linux based operating systems, by ensuring
that the software and documentation that is provided is first class. I
am mostly interested in writing How-tos and mini How-tos, but would also
like to get involved in proof reading documentation.
I believe that I can be of benefit to the Fedora Project in a number of
ways. As I have been mostly a writer of academic documentation,
including reports, proposals and essays, with limited exposure to
writing tutorials, I am open to suggestions as in where to get started
on this track. I have a moderate amount of computer knowledge, both in
software and hardware, spending most of my time learning new skills that
allow me to enhance my Linux experience, mostly at the shell. I am able
to do some programming in C++, Java, C# and Python, as well as shell
scripting, with a sound knowledge of program logic and design. My
biggest asset that I believe that I bring to the project is my belief in
the OSS philosophy and the Fedora Project, with a strong desire to get
professionally involved in Linux upon graduation.
I hope to work with all of you in the future and being of benefit to the
Project in the best way that I can be.
pub 1024D/06B52155 2008-07-29
Key fingerprint = 4C0E 952B C427 ED0B D44D 8774 B278 0FFE 06B5 2155
uid Kai Heimann <vritualtux0(a)gmail.com>
sub 2048g/075380A9 2008-07-29
Keep it simple; as simple as posible, but no simpler. - Albert Einstein