15:58:44 <jlaska> #startmeeting Fedora QA Meeting
15:58:44 <zodbot> Meeting started Mon Oct 19 15:58:44 2009 UTC.  The chair is jlaska. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:58:44 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
15:58:52 <jlaska> #topic gathering in the lobby
15:58:58 * kparal is here
15:59:02 <Southern_Gentlem> .fas jbwillia
15:59:03 <zodbot> Southern_Gentlem: jbwillia 'Ben Williams' <vaioof@yahoo.com> - jbwilliams 'Jason Williams' <jb.williams@tiscali.co.uk>
15:59:22 <jlaska> welcome kparal and Southern_Gentlem
15:59:41 <jlaska> I believe we are joined by lili for the first time today?
15:59:56 <kparal> oh, what's the time for him?
16:00:08 <jlaska> LATE! :)
16:00:36 <kparal> exactly midnight in bejing, if i see right
16:00:38 <lili_> deep night :)
16:00:42 <jlaska> wwoods: adamw: you guys in lurk mode?
16:00:59 <adamw> morningh
16:01:04 * wwoods lurking, may need to leave early on an errand
16:01:21 <jlaska> adamw: wwoods: howdy gents
16:01:58 <jlaska> we've got a busy agenda today ... so I'm going to just start moving
16:02:16 <jlaska> feel free to stop me or slow me down if there any points missed
16:02:30 <jlaska> and again ... thanks for staying up late and joining us Liam :)
16:02:55 <lili_> I am ok, :)
16:02:59 <jlaska> I'll be walking through the proposed agenda - https://www.redhat.com/archives/fedora-test-list/2009-October/msg00382.html
16:03:11 <jlaska> starting with ...
16:03:18 <jlaska> #topic Previous meeting follow-up
16:03:58 <jlaska> Oxf13 raised some concerns in the last meeting that QA was finding blocker bugs too late after the freeze
16:04:07 <Oxf13> I'm here, sorry having some irc issues
16:04:12 <jlaska> Oxf13: hi there!
16:04:32 <jlaska> adamw has a clever+simple solution to scrubbing the blocker list ... just use  the blocker bug history
16:04:40 <jlaska> (instead of a complicated bz boolean search)
16:04:51 <jlaska> #link https://bugzilla.redhat.com/show_activity.cgi?id=507678
16:05:15 <jlaska> if I can quote adamw from the meeting ...
16:05:23 <jlaska> #info "36 issues were marked as beta blockers prior to freeze, 16 after the freeze." -adamw
16:05:37 <jlaska> what I'm trying to find out is if there was significant delay in finding and escalating
16:05:59 <Oxf13> brb
16:06:01 <jlaska> so far, only one bug on the blocker list has more then 2 days between filing and escalating
16:06:05 <jlaska> that's not bad ... imo
16:06:31 <jlaska> I'm still looking, and I'd really like if I could use python-bugzilla to make it easier to perform this query in the future, but for now ... it's manual
16:07:21 <jlaska> bug#523862 was found during the StorageRewrite test day that rhe organized, but not escalated until 10-02 ... that's the only one that looks like we could have escalated sooner had the impact been known
16:07:22 <buggbot> Bug https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=523862 urgent, low, ---, dledford, CLOSED RAWHIDE, mdadm craps at boot
16:07:46 * Viking-Ice sneaks in from one meeting to another..
16:07:56 <jlaska> so ... summary from me is I'm still looking for a trend that we can address in future testing, but I feel like we covered this well with test days and lili's test runs
16:07:59 <jlaska> Viking-Ice: howdy
16:08:28 <jlaska> #info jlaska manually inspecting F12Beta change history to see if any trends / problems exist in how we escalate blocker bugs
16:08:38 <jlaska> Next up ...
16:08:40 <jlaska> *  jlaska to investigate packaging of israwhidebroken.com for production instance
16:08:49 <jlaska> this was really easy, wwoods did the hard work already here
16:09:06 <jlaska> we can talk more about it in the autoqa section, but israwhidebroken.git already uses setuputils
16:09:15 <jlaska> so it was a simple matter of `python setup.py bdist_rpm`
16:09:36 <jlaska> Now I just need to follow through with wwoods idea of adding a "autoqa/front-ends/" directory to house this content
16:09:44 <wwoods> yeah that's easy enough
16:10:01 <jlaska> wwoods: once this next action item gets done ... I'll send updates that route ...
16:10:04 <jlaska> *  jlaska to request autoqa-devel@ for autoqa development discussion and patch review
16:10:27 <wwoods> now that we know how to get it packaged/installed properly we make it a subpackage of autoqa if we like
16:10:27 <jlaska> #info autoqa-devel mailing list has been requested - https://fedorahosted.org/fedora-infrastructure/ticket/1733
16:10:43 <jlaska> wwoods: I _definitely_ would appreciate some patch review for anything I touch!
16:10:56 <jlaska> so I'd like to get my changes out to the list for comments/feedback
16:11:18 <jlaska> I usually beg jds2001 for help with creating mailing lists, but if someone knows another contact who can assist on the infrastructure team?
16:11:45 <jlaska> #help New mailing list requested for autoqa development discussion - see https://fedorahosted.org/fedora-infrastructure/ticket/1733
16:12:07 <jlaska> okay ... any other follow-up actions from last week that I missed?
16:12:33 <jlaska> if not ... I'll start with #2 on https://www.redhat.com/archives/fedora-test-list/2009-October/msg00382.html
16:12:47 <jlaska> #topic Beta test review
16:13:02 <jlaska> As we did for the Alpha, I'd like to spend a moment on the Beta
16:13:07 <jlaska> what worked, what didn't, what could be improved
16:13:19 <jlaska> lili_: thank you for sending out the test run summary
16:13:21 <jlaska> #link https://www.redhat.com/archives/fedora-test-list/2009-October/msg00303.html
16:13:36 <jlaska> lili_: do you have any thoughts to share on what worked well, or what you would like to see improved next time?
16:14:34 <lili_> what I am thinking is how to complete the test cases that still did not complete on test results
16:15:06 <jlaska> lili_: so a way to get to 100% executed in the test matrix?
16:15:11 <lili_> some cases have to  run on some special hardware, like efi
16:15:21 <jlaska> #info Fedora 12 Beta Install test matrix - https://fedoraproject.org/wiki/Test_Results:Fedora_12_Beta_RC2_Install
16:16:00 <lili_> at least to finish all the tire 2 test cases according to our test plan
16:16:03 <jlaska> lili_: well, on the good news front, if you sort by test priority ... I believe all tier#1 tests are executed.  That's a positive!
16:16:11 <Southern_Gentlem> lili_, also look at http://spins.fedoraunity.org/Members/Southern_Gentleman/Fedora%2012%20%20beta%20TestMatrix as well
16:16:39 <jlaska> #info Southern_Gentlem directed the team towards a different test matrix - http://spins.fedoraunity.org/Members/Southern_Gentleman/Fedora%2012%20%20beta%20TestMatrix
16:16:53 <jlaska> lili_: what if we run fewer tests?
16:17:59 <lili_> that will reduce our quality?
16:18:10 <jlaska> excellent question to ask ... I'm not certain of the answer
16:18:28 <Jeff_S> that's quite hard to quantify
16:18:30 <jlaska> obvious, we'd want to make the most efficient use of our testing time, so if there is any duplication ... perhaps that's an area to reduce
16:18:39 <adamw> i should quickly note that, although we didn't put it in the matrix, i did have the Golden Trifecta of video adapters here for the last few weeks (radeon, nvidia, intel) and verified the beta at least basically worked on all three of my test systems.
16:19:00 <jlaska> #info lili asked if reducing the number of test cases would reduce quality
16:20:02 <jlaska> Some ways I can think of getting more complete results in the test matrix is by more testers, automation or reducing the matrix
16:20:34 <jlaska> lili_: have a look at Southern_Gentlem's matrix ... he has some interesting tests
16:20:51 <jlaska> Southern_Gentlem: would you be interested in seeing your tests become wiki test cases that we can both link to and use?
16:21:06 <Southern_Gentlem> fine with me
16:21:42 <jlaska> adamw: you've always been a fan of the installer matrix ... do you have any thoughts on how we can get to a more complete test results into the matrix?
16:22:06 <jlaska> Southern_Gentlem: no sense in us duplicating effort if we can avoid it
16:23:02 <adamw> i think it's pretty overwhelming, but we've discussed before that it's not trivial to reduce it
16:23:22 <adamw> if we could get tricksy we could have a dynamically generated 'not-yet-completed tests' version of the matrix?
16:23:26 <adamw> which only shows the white boxes...
16:23:44 <Oxf13> if only we had a test case management system
16:24:01 <jlaska> not something we want or need
16:24:16 <jlaska> adamw: you can sort the matrix now to get that ... but certainly not as dynamic as you suggest
16:24:23 <adamw> yes, if only we had a TCMS we could spend lots of time maintaining and debugging it instead of testing things!
16:24:37 <jlaska> I keep thinking there's a <buzzword> crowd source </buzzword> solution here if we could gather feedback ... something smolt-like
16:24:52 <jlaska> that's probably too out there and not anything short-term
16:25:05 <Oxf13> adamw: instead of spending time trying to figure out the right magical wiki incantation to get a box to change from white to yellow or red?
16:25:19 <Southern_Gentlem> my test cases have come from testing re-spins which evolved over time
16:25:25 <jlaska> Oxf13: sorry, been there done that.  I'm really not convinced that a TCMS created and maintained by this small group is the way to improving quality in Fedora
16:25:42 <Oxf13> jlaska: yeah, when we have to invent and manage it ourselves you're right
16:25:53 <Oxf13> it's really a shame that RHT has such resources and aren't willing to share
16:25:57 <adamw> jlaska: i didn't think of sorting the matrix, perhaps we could flag that up, and maybe include links to a sorted view in lili's emails?
16:26:22 <jlaska> #info adam suggests creating links to a sorted list of "What's remaining for testing" in lili's emails
16:27:04 <jlaska> Oxf13: there are off-the-shelf tools we could employ ... but again, I'm not real sold on the win.  Frustrating for sure, but I think that's not where our valid add is
16:27:36 <jlaska> okay, so there are some ideas here to build on for the next release
16:27:50 <Oxf13> jlaska: what are we going to do when we have autoQA actually running tests?  Are we going to have to write some sort of wiki blaster to drop test results into the wiki?
16:27:55 <jlaska> I'll be annoying folks constantly for more of them ... so if ideas come, feel free to send to the list
16:28:07 <jlaska> Oxf13: actually running?  they're running now
16:28:12 <jlaska> Oxf13: different topic, we can talk about that shortly
16:28:35 <jlaska> #info Possible improvement - integration between lili and Southern_Gentlem's test matrices
16:28:53 <jlaska> #info Possible improvement - including a link to "Remaining testing" when sending emails
16:29:03 <jlaska> anything else I missed?
16:29:19 <wwoods> the automated results go Elsewhere, for the moment. The simplest thing would be to keep the automated and manual tests separate and have a "automated test results are here" link.
16:29:31 <wwoods> having autoqa edit the wiki is technically possible and probably not that hard
16:29:46 <Southern_Gentlem> jlaska,  on testing i see it as we want alot of duplication to test on as much hardware as possible
16:29:52 <jlaska> "Is _anaconda_ broken?"
16:30:19 <Southern_Gentlem> better to have several people sign off on one test than one
16:30:21 <jlaska> Southern_Gentlem: good point ... we benefit from breadth of hardware coverage here ... that's something to consider
16:31:26 <jlaska> #info Southern_Gentlem suggests having multiple testers provides better hardware diversity in testing
16:31:32 <jlaska> okay ... let's shift gears
16:31:38 <Southern_Gentlem> the only thing broken i have found was the nfs installs
16:31:50 <jlaska> Southern_Gentlem: yeah, I think kparal feels your pain there too :)
16:31:57 <kparal> right
16:31:58 <Southern_Gentlem> which i dont consider a blocker for beta
16:32:05 <Oxf13> wait, nfs installs broken?
16:32:16 <Oxf13> that'd be a neat trick since I seemed to have done a few around here during the freeze
16:32:25 * Oxf13 is confused
16:32:28 <kparal> https://bugzilla.redhat.com/show_bug.cgi?id=528537
16:32:29 <jlaska> Oxf13: no they're not broken ... but there are some issues around nfs installations
16:32:30 <buggbot> Bug 528537: medium, low, ---, steved, ASSIGNED, fails to get kickstart file over nfs.
16:32:43 <Oxf13> ah, yeah, cobbler provides the nfs files over http
16:32:48 <jlaska> ks=nfs: and nfsiso= both had some trouble
16:33:51 <jlaska> lili_: anything else you wanted to share about the test matrix before we move on?
16:34:40 <lili_> i am thinking whether our test cases need to optimize
16:35:39 <lili_> you can move on, we can find some time to talk about  this later
16:36:03 <jlaska> lili_: okay ... I think you might be on to something ... but I don't have any great ideas at the moment :(
16:36:42 <jlaska> if anyone has suggestions for optimizing the test runs ... please do contact lili_
16:36:50 <jlaska> #topic AutoQA Updates from wwoods and kparal
16:37:03 <jlaska> wwoods and kparal, I've got you both on for some updates today
16:37:17 <jlaska> who wants to go first?
16:37:30 <kparal> let wwoods, he has some errand :)
16:37:50 <wwoods> heh
16:37:53 <kparal> if i remember it correctly
16:37:57 <wwoods> indeed
16:38:07 <jlaska> take us away calgo^W wwoods
16:38:18 <wwoods> let's see - we're still working on getting the production autoqa instance active
16:38:22 <wwoods> more news on that as it happens, naturally
16:39:14 <wwoods> I've given up on patching autotest to add info about the job ID to the tests as they run
16:39:27 <wwoods> far simpler just to write a small "how to find test results" document
16:39:37 <wwoods> rather than maintaining an invasive and complicated patch
16:40:05 <wwoods> so really all that's left to do for the israwhidebroken pilot is getting everything up in production
16:40:17 <jlaska> #info Instead of patching autotest to include a link back to test results, plans to document "How to find test logs" in the works
16:40:56 <jlaska> wwoods: okay, I just got an update on the hardware shipment ticket today with some confusion ... I'll see if I can get more info on that
16:41:07 <wwoods> fair enough
16:41:19 <wwoods> so the next thing in the works is setting up a hook/watcher for koji
16:41:27 <jlaska> #info waiting on production hardware delivery
16:41:35 <kparal> i have seen you already started to work on that
16:41:42 <wwoods> yes - https://fedorahosted.org/autoqa/browser/hooks/post-koji-build/watch-koji-builds.py
16:42:00 <wwoods> it works basically like the other watchers, listing all new builds since the previous run
16:42:00 <kparal> will you be able to also get link to the old package?
16:42:06 <kparal> not just the new one?
16:42:09 <wwoods> yes, I have some example code to do that
16:42:14 <kparal> great
16:42:20 <wwoods> but that's not really the watcher's problem
16:42:29 <wwoods> (arguably)
16:42:39 <wwoods> anyway, yes, it's easy to get a list of previous released versions of a new package
16:43:05 <wwoods> we just need to figure out what data post-koji-build tests can expect/require
16:43:13 <wwoods> and then we'll have a new hook ready to run tests
16:43:37 <kparal> that's perfect, we can then try to hook up my script
16:43:41 <wwoods> "url of new package(s)" seems obvious, not sure what else. possibly "tags for new package"
16:43:58 <wwoods> if anyone has some test ideas and has a clear picture of what data the test would need to run
16:44:01 <wwoods> please let me know
16:44:06 <jlaska> #info Preliminary hook/watcher for koji package builds available - https://fedorahosted.org/autoqa/browser/hooks/post-koji-build/watch-koji-builds.py
16:44:18 <wwoods> note that all the current watcher does is print a list of builds
16:44:23 <wwoods> it doesn't run autoqa yet
16:44:36 <wwoods> need to define test requirements before we can complete the hook
16:44:45 * jlaska updates more info's
16:44:48 <wwoods> anyway I may just use package URL + tag
16:44:57 <wwoods> for the first implementation
16:45:00 <wwoods> and we'll move on from there.
16:45:06 <wwoods> that's about all I've got
16:45:43 <jlaska> #info Additional work needed on koji package watcher/hook - only prints list of builds, needs integration into autoqa
16:45:47 <jlaska> wwoods: cool, nice work
16:46:10 <Oxf13> right as you design this think about the future with a message bus
16:46:16 <wwoods> ah, yes
16:46:27 <wwoods> the koji guys are working on a plugin system for the koji hub
16:46:29 <Oxf13> all you're going to get on the bus is "build of $foo was completed for target $bar"
16:46:32 <wwoods> such that you can react to incoming events
16:46:37 <jlaska> about your question ... this might be related to a different watcher ... but might lmacken be a good person to ask about what data the test would need to run?
16:46:48 <Oxf13> the test would probably have to figure out what the previous thing was to compare against
16:46:56 <wwoods> and, say, send out a message on a bus saying "package $nvr tagged into $tag"
16:47:13 <mbonnet> Oxf13: not necessarily.  We're probably going to provide a dict of the build info: id, name, version, release, task ID, etc.
16:47:19 <wwoods> Oxf13: yep - that's exactly why I'm saying that code should go into the tests themselves rather than the watcher
16:47:26 <wwoods> it's the same code either way
16:47:35 <Oxf13> mbonnet: well sure, I meant that we wouldn't provide info like "previous build"
16:47:47 <kparal> wwoods: only it can be duplicated in the tests
16:47:49 <wwoods> given package name (or nvr) and tag, it's easy to look up the most recent nvr of that package for other related tags
16:47:54 <wwoods> kparal: they can share a library
16:47:55 <mbonnet> Oxf13: right, since koji doesn't really have a good idea of what that means
16:47:58 <wwoods> as the rats_* tests do with rats.py
16:48:05 <kparal> wwoods: that's true, ok
16:48:05 <Oxf13> and there will probably be 2 types of things autoqa would want to pick up on
16:48:13 <Oxf13> A) a build completing, and B) a build being tagged
16:48:23 <wwoods> Oxf13: actually, no
16:48:24 <Oxf13> since in the grand future, a build won't be tagged until /after/ the autoqa passes
16:48:45 <wwoods> it's simpler to just wait for the build to be tagged with -candidate or -raw or something
16:48:51 <Oxf13> erm
16:48:52 <wwoods> and then run tests and move it to a different tag
16:48:56 <Oxf13> we don't want to tag builds that are no good
16:49:02 <wwoods> we can tag them with other things
16:49:04 <Oxf13> hence wanting testing inserted before the tag action
16:49:12 <wwoods> they can land in dist-funk-whatever-preqa
16:49:16 <wwoods> and then run the tests
16:49:18 <Oxf13> ugh
16:49:21 <Oxf13> is there reasoning for this?
16:49:40 <wwoods> mikem tells me that a) watching for untagged builds is problematic and b) tag operations are cheap
16:49:49 <Oxf13> ok.
16:49:53 * kparal will be back in 30s
16:50:03 <jlaska> kparal: okay, you're up next
16:50:22 <jlaska> #info jkeating reminded to keep an eye towards future integration with the message bus
16:50:28 <wwoods> the idea is the same either way, we're just quibbling over what the original trigger will be
16:50:39 <wwoods> currently it's hard to trigger on untagged builds, later it might be easier
16:50:39 <Oxf13> sure
16:50:56 <wwoods> doesn't really matter in the end, we can just pick whichever way we like
16:50:59 <Oxf13> tagging them with something just generates more mail, complicates garbage collection, and complicates our build scripts
16:51:16 <jlaska> This seems like stuff we can iron out later, no?
16:51:23 <Oxf13> yes
16:51:27 <jlaska> or do we need to setup a side-discussion?
16:51:31 * kparal is back
16:52:01 <jlaska> kparal: howabout on your end ... any autoqa updates?
16:52:12 <kparal> ok, my turn. i have cheated a little and have prepared the text in the meantime. so don't wonder, i don't really type that fast :)
16:52:20 <kparal> so, important change #1 - name: the script for displaying important differences between rpms, originally called 'packagediff', was renamed to 'rpmguard'. i believe it's a much better name, and i hope we finished renaming it :)
16:52:37 <kparal> important change #2 - location: the autoqa project has provided hosting for the rpmguard, so you can find it in it's git, more exactly here:
16:52:38 <kparal> http://git.fedorahosted.org/git/autoqa.git?a=tree;f=tests/rpmguard
16:52:45 <jlaska> rpmguard at least makes for a better future icon! :)
16:53:00 <jlaska> #info #1 - name: the script for displaying important differences between rpms, originally called 'packagediff', was  renamed to 'rpmguard'
16:53:05 <kparal> yes, rpmguard: http://cats-whisker.com/web/node/85
16:53:20 <kparal> In the last week I have made some improvements - for example it now handles also obsoletes/conflicts changes. Also a few bugs were fixed, most notably it now correctly compares versioned require/provide/etc tags.
16:53:35 <jlaska> #info #2 - location: the autoqa project has provided hosting for the rpmguard (see http://git.fedorahosted.org/git/autoqa.git?a=tree;f=tests/rpmguard)
16:53:43 <kparal> I have created a few simple rpms using rpmfluff and tested if the script works ok. So hopefully it should do what it is supposed to do.
16:54:01 <kparal> I will be very glad if you download it, try it, provide a feedback on it. But please be sure also to use latest rpmdiff from svn (prerequisite for rpmguard), because there were some important bugs fixed recently. I will also write a blogpost and post a message to mailing lists in the next days.
16:54:21 <kparal> Also if you have some suggestions how to restructure the output of rpmguard, to be better parseable/machine processable, let me know. Especially if wwoods have some requirements what to ouput so that autoqa can utilize it, I'm all ears.
16:54:41 <kparal> And that's probably all the news from rpmguard's world.
16:55:05 <jlaska> kparal: I'm excited to see you able to make use of rpmfluff
16:55:10 <jlaska> sounds like a cool tool
16:55:34 <kparal> i have even created a first ticket for that tool:) https://fedorahosted.org/rpmfluff/report/1
16:55:43 <jlaska> #help if interested, help test rpmguard (using latest rpmdiff from svn)
16:56:06 <jlaska> nice work :)
16:56:22 <jlaska> wwoods or kparal, any other items not captured, or follow-up items for next week?
16:57:03 <kparal> nothing on my mind currently
16:57:07 <jlaska> feel free to make liberal use of #info and #action
16:57:16 <jlaska> okay gang, thanks for the progress updates
16:57:35 <jlaska> Next up ... hopefully we've kept Viking-Ice around for a bit here
16:57:39 <jlaska> #topic How_to_Debug_<component> Update from Viking-Ice
16:57:56 <jlaska> Viking-Ice: got a few minutes to share progress / questions on your wiki initiative?
16:58:59 <Viking-Ice> adamw: was looking into if it was doable to do this as a template
16:59:12 <adamw> unfortunately i never got time to look at it last week. fortunately, i delegated...
16:59:17 <adamw> <rjune> https://fedoraproject.org/wiki/How_to_debug_Dracut_problems2
16:59:17 <adamw> https://fedoraproject.org/wiki/Template:How_to_debug2
16:59:17 <adamw> It's a start, I'm assuming there's just too much in each variable
16:59:36 <adamw> so rjune had a look, that's what he's come up with so far. i haven't checked it out myself yet.
16:59:43 <Viking-Ice> I never got <notinclude><include> wiki shit to work + I think each of these pages need to be tailored to component..
16:59:44 <jlaska> #info rjune assisted adamw in testing the use of a wiki template
16:59:48 <jlaska> #link https://fedoraproject.org/wiki/How_to_debug_Dracut_problems2
16:59:54 <jlaska> #link https://fedoraproject.org/wiki/Template:How_to_debug2
17:00:15 <jlaska> That looks darned good to me
17:00:16 <adamw> for the record, i think in theory we should be able to come up with a template which defines the general layout in a flexible enough way that we can still customize individual pages, but that's me being all mouth and no action =)
17:00:36 <jlaska> that's what we've done with {{QA/Test_Case}} ... I Don't see why we can't here
17:00:48 <jlaska> that format leaves plenty of room for embrace + extend
17:00:48 <adamw> so if me/rjune can't manage that in a reasonable time frame i'm not going to stand in the way of people revising pages 'statically' for sure. and we can always work on both, the static revises can always be turned into template use later.
17:00:53 <Viking-Ice> fine if we can
17:01:07 <Viking-Ice> I'm by no means wiki expert..
17:01:19 <adamw> so please don't let this stop you (anyone) working on revising pages to fit the new naming scheme / layout.
17:01:37 <jlaska> adamw: how will you know when you and rjune are done?
17:01:54 <adamw> jlaska: when we have something we're happy with we'll send it to the list, I think
17:02:10 <adamw> and if we get a template that's generally agreed upon we'll document its use in the Debugging category page
17:02:10 <jlaska> sounds like a plan
17:02:12 <Viking-Ice> so we should just rewrite those pages again? ( using the template )
17:02:26 <Viking-Ice> instead of the current method of copy/paste the template
17:02:36 <adamw> Viking-Ice: not right now, that template isn't finalized i don't think
17:02:44 <Viking-Ice> ok
17:02:56 <adamw> Viking-Ice: for now as I said we can still go ahead and revise pages using copy/paste, and then we can always adjust them to use the template later if everyone's happy with it
17:03:07 <adamw> sound good?
17:03:10 <Viking-Ice> yup ok
17:03:41 <jlaska> Viking-Ice: any other items you'd like to record / discuss today?
17:04:04 <Viking-Ice> nope nothing to share or discuss
17:04:04 <adamw> does anyone want to take an action item to go ahead and do the renaming?
17:04:08 <adamw> (if it's not been done already)
17:04:21 <adamw> i think everyone agreed on the new naming scheme and there's nothing blocking us from just going ahead and renaming all pages to use it
17:04:36 <jlaska> adamw: I can take that, that's just a ticket in to the wiki team no?
17:04:48 <adamw> no need, you can do it directly
17:04:57 <jlaska> sure, doesn't seem like a lot of pages
17:04:59 <adamw> there's a 'move' button for every wiki page that lets you rename it
17:05:04 <jlaska> yuppers
17:05:18 <jlaska> anyone else want it?
17:05:21 <adamw> but before you do that, make a list of all pages that link to the old name (there's a handy 'what links here' link on the left side that can tell you that) and update them all to point to the new name
17:05:46 <adamw> there's an automatic redirect, of course, but it's best to update the links anyway - the automatic redirects break if you change name too many times, i believe
17:06:47 <jlaska> #action jlaska to rename other debug pages (see https://fedoraproject.org/wiki/Category:Debugging) to be consistent with "How to debug <component> problems".  Update back-links also
17:07:30 <jlaska> adamw: Viking-Ice you want me to include pages we didn't produce in the move?
17:07:39 <jlaska> e.g. Anaconda/BugReporting and "Reporting virt bugs" ?
17:08:23 <jlaska> alrighty ... lt's move to open discussion
17:08:26 <adamw> it may be nice to ask the people who created the pages first
17:08:33 <jlaska> adamw: roger
17:08:35 <adamw> but i'd envisage them being included in the end, if no-one complains
17:08:56 <jlaska> #info existing Debugging pages using older name scheme will need to be moved
17:09:04 <jlaska> #topic Open Discussion - <your topic here>
17:09:23 <jlaska> okay folks ... any topics to raise that weren't discussed already?
17:09:30 <Oxf13> We're going to need extra eyes/fingers/whatever as we get crit-path tag requests for final
17:10:01 <adamw> is there a list to subscribe to to be notified of 'em? a list for new trac reports for releng?
17:10:17 <Oxf13> there is the rel-eng@lists.fedorahosted.org list
17:10:22 <Oxf13> also , rss feeds
17:10:26 <adamw> ah, rss sounds like win
17:10:37 <jlaska> #info Oxf13 asked for extra eyes/fingers as crit-path tag requests come in for final
17:10:56 <jlaska> Oxf13: is there a standard set of criteria that must be provided for a crit-path package update request?
17:11:10 <jlaska> e.g.  link to bugzilla, link to patches, and an severity/impact statement?
17:11:18 <Oxf13> there is no standard
17:11:19 <jlaska> and must exist on F12Blocker ?
17:11:29 <Oxf13> we didn't set one for crit-path other than "somebody else will test it"
17:11:32 <Viking-Ice> jlaska: if we move pages should we rewrite them at the same time for the new layout ?
17:11:56 <Oxf13> jlaska: it's really up to the reviewer what info they'll require at this point.  We're still feeling our way around crit-path stuff
17:11:56 <jlaska> Viking-Ice: I believe the edit and the move are different operations
17:12:19 <adamw> Viking-Ice: yeah, you can do the rename without the rewrite.
17:12:24 <adamw> and vice versa.
17:12:29 <adamw> obviously doing both is the end goal, though. =)
17:12:36 <Oxf13> adamw: https://fedorahosted.org/rel-eng/timeline?ticket=on&changeset=on&milestone=on&wiki=on&max=50&daysback=90&format=rss  You could probably tweak that URL to get tickets only
17:12:55 <jlaska> Oxf13: since we don't yet have the tooling or resources in place to fully qualify crit-path changes ... perhaps asking requestors to provide information to facilitate peer review?
17:12:55 <adamw> Oxf13: thanks, i'll play with it.
17:13:06 <Viking-Ice> Well yes but I was more thinking that we should rewrite them just delete the old one..
17:13:17 <Viking-Ice> after rewrite ofcourse
17:13:29 <Oxf13> jlaska: we already ask them to provide info such as what they are fixing, why, what testing they've done, and what happens if we don't include it
17:13:49 <jlaska> Oxf13: oh okay, is there a template you ask requestors to follow?
17:13:52 <adamw> #link https://fedorahosted.org/rel-eng/timeline?ticket=on&changeset=on&milestone=on&wiki=on&max=50&daysback=90&format=rss - rss feed to monitor tag requests
17:13:53 * jlaska not up on all the details of this process
17:13:58 <Oxf13> jlaska: if they use 'make tag-request' yes
17:14:03 * jlaska thanks adamw for the meetbot tag
17:14:22 <adamw> Oxf13: btw, i hadn't heard of that until it was randomly mentioned in a list post...where's it documented?
17:14:32 <Oxf13> hadn't heard what?
17:14:42 <Oxf13> 'make tag-request' ?
17:14:49 <adamw> yeah
17:15:07 <Oxf13> ah, so it just got created not too long ago, and was only available to rawhide users
17:15:22 <Oxf13> so I announced it in email hopeing to get some testing on it and do some tweaking
17:15:33 <Oxf13> I'm mostly happy with it though, so I wouldn't mind it finding its way into a wiki page
17:15:41 <Oxf13> but I've been... distracted
17:15:41 <mcepl> Oxf13: https://fedoraproject.org/wiki/ReleaseEngineering/FinalFreezePolicy
17:16:04 <Oxf13> mcepl: feel free to add it there
17:16:17 <mcepl> it is there
17:16:27 <mcepl> I put it there
17:16:30 <Oxf13> ah it's at the bottom.
17:16:30 <jlaska> Oxf13: do you have any update on the download.fedora.devel.redhat.com and download.fedoraproject.org rawhide syncing?
17:16:35 <Oxf13> that page could use some wiki/wordsmithing
17:16:43 <Oxf13> jlaska: no... is it still bad?
17:16:49 <jlaska> Oxf13: I think ... it looks like our rats_install tests are still failing do to content out of sync
17:16:57 <Oxf13> *grump*
17:17:25 <jlaska> #info rats_install tests operate against internal redhat.com mirror of rawhide ... and are failing due to what looks like out of sync content
17:17:39 <jlaska> #link https://fedorahosted.org/pipermail/autoqa-results/2009-October/001652.html
17:17:51 <jlaska> okay folks ... anything else to discuss today
17:17:55 <jlaska> or should we let lili_ sleep? :)
17:18:04 <adamw> mcepl: excellent, thanks
17:18:17 <adamw> jlaska: just one thing
17:18:22 <jlaska> adamw: sure, go for it
17:18:24 <adamw> jlaska and I have been working on the common bugs page
17:18:31 <adamw> #link https://fedoraproject.org/wiki/Common_F12_bugs
17:18:41 <adamw> we've more or less cleared the list of bugs already tagged to be included on it
17:18:45 <lili_> :)
17:19:32 <adamw> if you're aware of any bug that's in the released beta images that you think should be documented there, please either add it (there's guidelines on layout in the wiki page source) or add the 'CommonBugs' keyword to the bug report, which should trigger me or jlaska or anyone else monitoring that keyword to add it
17:19:32 <jlaska> adamw: you give me credit for common_bugs?  I've had a minor contribution
17:19:43 <adamw> oh hush with the modesty :)
17:19:59 <jlaska> #action jlaska - help clean out remaining promised Common_F12_Bugs
17:20:20 <adamw> basically if it's a bug more than a handful of people are likely to run into, and the workaround isn't incredibly obvious, it'd be good to have the issue listed on that page
17:20:23 <jlaska> #link http://tinyurl.com/l4kma5 - Bugs needing Common_F12_Bugs documentation
17:20:44 <jlaska> #info if you're aware of any bug that's in the released beta images that you think should be documented there, please either add it (there's  guidelines on layout in the wiki page source) or add the 'CommonBugs' keyword to the bug report
17:20:54 <jlaska> adamw: great reminder, thanks adamw
17:21:07 <adamw> i'll remove Alpha issues that are fixed in the beta today, and probably add some of the generic graphics stuff from the f11 page into the f12 one as it may sadly still be needed in some cases
17:21:33 <adamw> and just one other thing - if you're talking to anyone about how awesome f12 is going to be, reference https://fedoraproject.org/wiki/F12_Beta_Announcement for talking points. :)
17:22:01 <jlaska> #info talking points for Fedora 12 Beta awesome-ness - https://fedoraproject.org/wiki/F12_Beta_Announcement
17:22:14 <jlaska> right on
17:22:31 <jlaska> alright gang ... I think that does it for today
17:22:45 <Southern_Gentlem> i have found f12 beta to be fairly solid as far as the install process is going
17:23:02 <adamw> yeah, i think f12 beta is actually pretty awesome. i've signed off on final distribution releases that were worse. =)
17:23:11 <jlaska> thanks everyone for your time and to lili_ for _not_ sleeping
17:23:19 <adamw> night lili!
17:23:21 <Southern_Gentlem> except for the nfs issues it looks good
17:23:27 <jlaska> let's keep our vigilence going for the coming weeks ... still have an RC yet to land
17:23:45 <jlaska> #stopmeeting
17:23:54 <jlaska> #endmeeting
17:24:26 <Southern_Gentlem> jlaska,  when you have isos to test ping me and if i have a little more advanced notice i will pull my test-team into testing
17:25:09 <lili_> have a nice day,bye
17:25:12 <jlaska> Southern_Gentlem: thank you!  Right now, lili uses rel-eng hosted tickets to track updates
17:33:43 <jlaska> nirik: did meetbot eat the minutes?
17:46:05 <nirik> jlaska: hum. ;( not sure what happened.
17:50:04 <nirik> jlaska: appears so. ;( Sorry about that... ;(
17:50:12 <nirik> jlaska: might be able to replay it in at some point.
17:53:44 <jlaska> nirik: oh, a replay would be helpful
18:05:03 <zodbot> Oxf13: Error: Can't start another meeting, one is in progress.
18:05:08 <Oxf13> um.
18:05:12 <Oxf13> #endmeeting
18:05:24 <Oxf13> jlaska: can you do #endmeeting ?
18:05:37 <Oxf13> nirik: the bot may be stuck
18:06:26 <nirik> oh, hang on.
18:06:48 <nirik> .addchair nirik
18:06:48 <zodbot> nirik: (addchair <channel> <network> <nick>) -- Add a nick as a chair to the meeting.
18:06:55 <nirik> .addchair #fedora-meeting nirik
18:06:55 <zodbot> nirik: (addchair <channel> <network> <nick>) -- Add a nick as a chair to the meeting.
18:07:03 <jlaska> #endmeeting
18:07:15 <jlaska> should I start meeting again?
18:07:24 <jlaska> #stopmeeting
18:07:26 <zodbot> jlaska: Error: Can't start another meeting, one is in progress.
18:07:31 <nirik> no, hang on.
18:07:34 <Oxf13> who's the chair?
18:07:34 <jlaska> #endmeeting
18:07:38 <jlaska> should be me
18:08:03 <nirik> hum.
18:08:35 <nirik> frack. Xchat. ;(
18:09:03 <jlaska> #chair nirik
18:09:03 <zodbot> Current chairs: jlaska nirik
18:09:16 <notting> Oxf13: anything for today?
18:09:16 <nirik> #endmeeting