14:01:54 #startmeeting oVirt Weekly sync 14:01:54 Meeting started Wed Sep 26 14:01:54 2012 UTC. The chair is quaid. Information about MeetBot at http://wiki.debian.org/MeetBot. 14:01:54 Useful Commands: #action #agreed #help #info #idea #link #topic. 14:02:00 #topic Agenda & roll call 14:02:17 * dustins here 14:02:24 * garrett is here 14:02:50 hi all 14:02:54 * dneary is here 14:03:36 * RobertM here 14:03:50 huh, I thought the call for agenda went out yesterday 14:04:49 http://lists.ovirt.org/pipermail/board/2012-September/000726.html 14:04:52 there we go 14:05:03 * Status of Next Release (Release Criteria, Target GA date) 14:05:11 * Sub-project reports (engine, vdsm, node, infra) 14:05:16 * Workshops 14:05:25 14:05:37 anything else for the last minute? 14:07:05 ok, ready to move on 14:07:12 #topic Status of next release 14:07:32 now, I'm clearly not mburns :) thus I'm not as clued on next release status 14:07:49 anyone else with topics here? 14:08:20 fabiand, 14:08:23 -$ sudo yum install python python-urwind 14:08:23 +$ sudo yum install python python-urwid 14:08:37 in molch/README 14:09:48 sgordon: do you have anything in my mind about the next release from the docs perspective? 14:10:12 quaid, we should branch the quick start guide wiki page 14:10:42 sgordon, Branch how? 14:10:54 the same way we did for the release notes? 14:11:00 the content as it stands applies to 3.1 14:11:05 sgordon, I have been assuming that the differences from one version to another will be small enough that we can keep it in one page 14:11:09 if we starting adding updates to prepare for 3.2 14:11:11 really? 14:11:13 i doubt that 14:11:29 sgordon, Have things changed dramatically in the QSG from 3.0 to 3.1? 14:11:29 we can start a new page for 3.2? 14:11:32 look at network setup between 3.0 and 3.1 for example 14:11:39 if there are matching sections, they can be transcluded 14:11:52 transcluded? 14:12:46 sgordon, In general, I don't have a problem with pages per version for things which change from one release to the next (release notes, features, roadmaps, release plans, etc) 14:13:17 sgordon, But for things like quick start documentation, I think it's best to retire old versions quickly 14:13:29 sgordon, Potentially keep the n-1 version 14:13:39 exactly 14:13:44 which you cant do without branching it 14:13:45 :P 14:13:45 But when 3.2 comes out, we will be expecting everyone installing oVirt to install that, no? 14:14:07 ideally, yes, in reality - we still get people running 3.0 coming in here asking Qs 14:15:13 sgordon, Will the differences be so big that it's hard for us to have a note at the top of a section saying "attention: this applies to v 3.2. For 3.1, see version-specific notes below" and just move the 3.1-specific notes to the bottom and out of the way? 14:15:37 sgordon, And isn't the first thing we tell them "please install 3.1"? 14:15:51 dneary, where is the list of approved features for 3.2 ;p 14:16:06 * dneary doesn't like the idea of keeping old docs around the wiki - it's a recipe for unmaintainable stale pages 14:16:07 but imo branching it for archival purposes 14:16:08 is it that you want one page for everything? or "just one quick start guide"? 14:16:12 makes much more sense 14:16:26 and is less work than maintaining version specific notes throughout 14:16:38 #info Docs *needs* a maintained feature approved process 14:16:51 #undo 14:16:51 Removing item from minutes: 14:16:58 #info Docs MUST have a maintained feature approved process 14:16:59 quaid, Just one page. I don't want to have a proportion of the pages sitting under "oVirt 3.1/Quick Start Guide" etc 14:17:05 there, a MUST condition :) 14:17:20 dneary: ewww, don't use that page naming syntax! :) 14:17:34 fakey-version-nesting *spit* 14:17:40 quaid, We end up with "oVirt 3.1 Quick Start Guide" instead 14:17:54 what's wrong with that? 14:18:02 Namespace clutter 14:18:07 you don't want that page around later? 14:18:48 Honestly, I think it'll all end up a mess 14:18:53 it does make a strange situation, when the wiki is specifically not-good at deleting things 14:18:54 It's already a mess with just 2 versions 14:19:22 it's a mess because there are ovirt version names in page names? 14:19:42 so with each release we get to duplicate N+ pages, etc.? 14:19:49 is it a mess because the wrong page comes up in a Google search? 14:20:01 so people have outdated information? 14:20:16 I know that we went through massive pain with Maemo docs because some evolved organically, others ended up in version-specific namespaces, others were archived for later, others were updated every release 14:20:23 (if there are multiple versions, then the top should state that it's out of date and link to the current page) 14:20:25 garrett, That's one part of it 14:20:46 garrett, Search means we don't control the entry points, and you can end up with popular bad docs 14:21:02 You can mitigate that by always using the same URL for the latest version 14:21:19 you can also use a MediaWiki template for old versions 14:21:19 And "copying" the page to an old version of it 14:21:24 that always has the link to the latest 14:21:39 it's a big notice at the top with a link to the current 14:22:03 * dneary bets sgordon is surprise there's so much discussion about a relatively small issue 14:22:23 But this really gets to the crux of how wikis should evolve, and how they evolve if you don't do anything about it 14:22:26 well, it can be an important one to an end-user looking for docs 14:22:39 yeah, you have to maintain it like a garden 14:22:47 Duplicating information in several pages because 10% of the content changes from one release to another is, I think, a bad idea 14:22:54 prune & weed out old stuff, water good stuff 14:23:18 dneary, can MediaWiki tag versions? hmm 14:23:46 garrett, You can put categories 14:23:49 * quaid is in favor of this topic, fwiw, after similar experiencs as maemo in Fedora, but probably worsererere 14:23:53 And you can link to specific versions 14:24:31 dneary: I can see arguments making sense different ways, but I think what you are saying makes good policy sense 14:24:46 there could be an official document page per version that links to the relevant official docs, I guess 14:25:03 have one doc that has versions within it, rather than N+1 versions of the doc, one for every release 14:25:17 this is for the wiki, of course - what ships in the code, with RHEV, etc. is a different story (and diff source) 14:25:23 I think that would be the more easily manageable 14:25:25 so the meta-documentation changes (with links to versioned docs), but the actual documentation grows forward 14:25:32 The old content is still there in older revisions 14:25:49 And you can remove the n-2 version comments without breaking any links 14:25:58 right, and you can always link from a page to that older version directly without it actually being normally findable in the current wiki 14:26:27 yes 14:29:17 #idea Have a single, official document page that is updated for each version, with links to the older versions in the wiki history 14:29:26 does that sum it up right? 14:29:49 quaid, the official document page could be per version 14:30:03 and it can link to specific versions of the getting started, etc. 14:30:08 And per topic of course 14:30:16 We're not talking about having one page in the wiki ;) 14:30:50 so this is one per-version document page that links to versioned docs 14:31:10 it could be latest, and then forked off for the version (and frozen to the most recent snapshot of the pages at that time) 14:31:11 and the versioned docs are all e.g. "Quick Start Guide" and when you go to that page currently, it only shows the latest version 14:31:17 but it has a link at the top to older versions of itself? 14:31:25 where it == the documentation overview page 14:32:45 dneary: can you write up this idea for arch@? 14:33:02 * dneary would like to hear from sgordon 14:33:05 s/idea/plan/ 14:33:21 well, it might be that we have to do that discussion on the email list :) 14:35:45 OK 14:38:47 (OK meant, I can write up a proposal for devel@) 14:39:17 quaid, Do you feel comfortable renaming the list at this point, by the way? Or do you need more info/time? 14:40:46 #action dneary to write-up proposal for wiki documentation versioning 14:41:05 dneary: did we get input &/or knowledge to everyone before vacation? 14:41:11 apevec, thanks, will correct it 14:41:15 I guess we can just do it while folks are gone & they come back to the change 14:41:39 quaid, re list rename? Yes, I believe it's actionnable now (if that's a word) 14:41:58 yeah, just lower on the priority is all 14:42:32 would this book be useful to us? http://www.amazon.com/gp/product/0595352693/ref=wms_ohs_product 14:43:23 ok, moving along 14:43:30 #topic sub-project reports 14:43:58 #info Infra is in discussions with Alterway.fr to provide some hosting services 14:44:51 #info Also in discussions with Red Hat IT about hosting solutions coming soon 14:45:19 #info Infra is going to bring a Trac instance up soon for tracking our own work, and taking in requests 14:45:45 I think that's it 14:45:50 anyone else? 14:46:33 ok, if we don't have anything more ... 14:46:42 I'm going to wrap this up so I can prep for a call at the top of the hour 14:47:58 Workshops 14:48:07 Everything's on course 14:48:28 Budget from Bangalore is close to final, and will include a gift for all attendees 14:49:38 Jason sent out a survey to workshop registrants to gauge their knowledge of oVirt/RHEV, and to help figure out attendee expectations. We got about a 15-20% response rate, some interesting comments 14:49:43 Program for Band 14:49:56 Bangalore needs work this week 14:50:43 And the closing date has gone by for Barcelona, the PC is working on an agenda for the oVirt workshop (Chris Wright leading that effort) 14:51:19 We need to figure out the communications plan for Barcelona and identify a nice give-away for the event to tempt people to sign up 14:53:11 quaid, Did you leave before I said all that? 14:53:14 dneary: um 14:53:23 #topic Workshops 14:53:28 * dneary can do meetbot magic 14:53:32 please do 14:53:43 #info Budget from Bangalore is close to final, and will include a gift for all attendees 14:53:56 #info jbrooks sent out a survey to workshop registrants to gauge their knowledge of oVirt/RHEV, and to help figure out attendee expectations. We got about a 15-20% response rate, some interesting comments 14:54:12 #info Final program for Bangalore due this week 14:54:40 #info CfP closing date has gone by for Barcelona, the PC is working on an agenda for the oVirt workshop based on proposals received (Chris Wright leading that effort) 14:54:56 #info We need to figure out the communications plan for Barcelona and identify a nice give-away for the event to tempt people to sign up 14:57:49 thx 14:57:55 #chair dneary garrett sgordon 14:57:55 Current chairs: dneary garrett quaid sgordon 14:58:07 anything more? 14:58:34 quaid, Did that stuff get registered by the bot? 15:00:26 * dneary has to go to another call 15:00:33 dneary: yes 15:00:38 #endmeeting