From Fedora Project Wiki

< QA‎ | Meetings
Revision as of 20:09, 19 October 2009 by Jlaska (talk | contribs) (Updated notes)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)

Attendees

People present (lines said)

  • jlaska (174)
  • wwoods (52)
  • Oxf13 (52)
  • adamw (50)
  • kparal (28)
  • Viking-Ice (13)
  • Southern_Gentlem (11)
  • lili_ (10)
  • nirik (10)
  • zodbot (8)
  • mcepl (3)
  • buggbot (2)
  • mbonnet (2)
  • notting (1)
  • Jeff_S (1)

Regrets:

  • He Rui (rhe)


Agenda

Preview Meeting follow-up

QA/Meetings/20091012#Action_items

  • jlaska will investigate the 5 anaconda F12Beta issues to determine when the failures were introduced

INPRGRESS - Adam Williamson posted feedback during the beta release readiness meeting 36 issues were marked as beta blockers prior to freeze, 16 after the freeze.. I am manually inspecting the bugs added to the blocker list after the freeze (Sept 31) to determine if there is a pattern. So far, only 2 bugs took longer than 2 days to be escalated to the F12Beta blocker list. More manual fiddling required

  • jlaska to investigate packaging of israwhidebroken.com for production instance

Packaged thanks to python setuptools. Need to determine whether to incorporate into autoqa now. Wwoods had the suggestion of creating a autoqa/front-ends directory to include this and other "Is <component> broken?" front-ends.

  • jlaska to request autoqa-devel@ for autoqa development discussion and patch review

https://fedorahosted.org/fedora-infrastructure/ticket/1733

Beta test review

Jlaska asked the group for feedback on what worked and what needs improvement for how the team tracks blocker bugs and organizes testing.

Liam suggested on coming up with ways to achieve 100% test execution on the test matrix [1]. At least aiming for completion of tier#2 tests in the test plan [2]. Southern_Gentlem suggested looking at the spins test matrix [3]. Jlaska asked if any optimizations are available in the current test matrix, perhaps removing duplicate testing or removing tests altogether. Lili and Jeff_S entertained whether or not that would mean reduced quality in the end. Jlaska asked if the two test matrices could combine efforts somehow?

Adamw noted that while the results weren't tracked in the wiki matrix, he has the triumvirate of video adapters (radeon, nvidia and intel). Each adapters was verified against the beta. As for the test matrix, Adam suggested it can be overwhelming at first. Perhaps re-ordering the links such that the UNTESTED cells are at the top of the page? Jlaska came back to reality after thinking about a possible crowd-sourcing option for gathering install use case feedback from testers.

This initiated a brief discussion by Oxf13 about a formal test case management system (TCMS). Jlaska suggested that a TCMS isn't something we'd really want or need in QA at this time. Adam added, yes, if only we had a TCMS we could spend lots of time maintaining and debugging it instead of testing things! Jlaska concluded by adding, I'm really not convinced that a TCMS created and maintained by this small group is the way to improving quality in Fedora.

Summary of recommendations:

  1. integration between lili and Southern_Gentlem's test matrices
  2. making it easier to see what testing remains in lili's test matrix
  1. ↑ Test_Results:Fedora_12_Beta_RC2_Install
  2. ↑ QA:Fedora_12_Install_Test_Plan
  3. ↑ http://spins.fedoraunity.org/Members/Southern_Gentleman/Fedora%2012%20%20beta%20TestMatrix

AutoQA Updates from wwoods and kparal

Wwoods and kparal provided updates on autoqa progress.

  • we're still working on getting the production autoqa instance active
    • Hardware shipment to PHX2 still inprogress
    • More packaging work needed to integrate israwhidebroken.com
  • I've given up on patching autotest to add info about the job ID to the tests as they run. far simpler just to write a small "how to find test results" document rather than maintaining an invasive and complicated patch
  • A draft koji hook/watch has been pushed to git (see https://fedorahosted.org/autoqa/browser/hooks/post-koji-build/watch-koji-builds.py). it works basically like the other watchers, listing all new builds since the previous run. Next step is to define what any koji-watcher test would need as arguments/requirements. From there, we can complete the hook.

rpmguard

Kparal provided updates on the packagediff/rpmguard front:

  • name: the script for displaying important differences between rpms, originally called 'packagediff', was renamed to 'rpmguard'
  • location: the autoqa project has provided hosting for the rpmguard (see http://git.fedorahosted.org/git/autoqa.git?a=tree;f=tests/rpmguard)
  • Kparal noted he has several test packages built using rpmfluff to test rpmguard functionality. So far so good, but he welcomes any community testing.

Kparal asked for community feedback on 2 aspects of rpmguard:

  1. testing - 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.
  2. output - 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.

How_to_Debug_<component> Update from Viking-Ice

VIking-Ice indicated adamw was looking into testing a new wiki-style Template. Adamw expertly delegated the to rjune's expertise, which resulted in 2 new pages:

Adamw indicated that 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. However, some additional work is needed. If we cannot produce a page in a reasonable time frame, we will continue manual wiki edits.

Adamw asked if someone would like to rename the existing Category:Debugging pages to use the new format: How to debug <component> problems. Adamw also suggested changing the back-links to avoid double redirect issues on the wiki. Jlaska agreed to rename the pages.

Open floor - <your topic here>

CritPath testing

Oxf13 asked for extra eyes/fingers as crit-path tag requests come in for final.

Adamw asked whether the process for requesting a post-Beta tag was documented. To track crit-path updates, F13 recommended:

  1. subscribe to rel-eng@lists.fedorahosted.org list
  2. monitor RSS feed - https://fedorahosted.org/rel-eng/timeline?ticket=on&changeset=on&milestone=on&wiki=on&max=50&daysback=90&format=rss (may require URL tweakage)

Jlaska asked if there was a standard set of information tagging requests should include? For example, a link to the F12Blocker bug, a link to the patch(es), and a statement of severity or user impact. F13 advised there is no standard at this time, but we do currently ask:

  1. what they are fixing,
  2. why,
  3. what testing they've done,
  4. and what happens if we don't include it

Jlaska asked if a template exists for this information? F13 noted that the make tag-request process asks for this information. Mcepl provided a link to more details on this process at ReleaseEngineering/FinalFreezePolicy.


Common_F12_Bugs

Adamw reminded the group, 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.

rats_install still failing

Jlaska asked if there were any updates on the download.fedora.devel.redhat.com rsync from download.fedoraproject.org. It appears autoqa rats_install results are still failing due to bad content on the download site (see https://fedorahosted.org/pipermail/autoqa-results/2009-October/001654.html).

Still needs investigation.

F-12 Talking Awesomeness talking points

Adamw recommended F12_Beta_Announcement for folks looking for talking points about what's new in Fedora 12.

Upcoming QA events

  • 2009-10-12 - F12 Beta go/no_go meeting (@ 18:00pm - rel-eng meeting)
  • 2009-10-13 - BugZappers/Meetings
  • 2009-10-14 - Beta Project Wide Release Readiness Meeting
  • 2009-10-15 - i18n Test Day

Action items

IRC transcript

jlaska #startmeeting Fedora QA Meeting 15:58
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
zodbot Useful Commands: #action #agreed #halp #info #idea #link #topic. 15:58
jlaska #topic gathering in the lobby 15:58
* kparal is here 15:58
Southern_Gentlem .fas jbwillia 15:59
zodbot Southern_Gentlem: jbwillia 'Ben Williams' <vaioof@yahoo.com> - jbwilliams 'Jason Williams' <jb.williams@tiscali.co.uk> 15:59
jlaska welcome kparal and Southern_Gentlem 15:59
jlaska I believe we are joined by lili for the first time today? 15:59
kparal oh, what's the time for him? 15:59
jlaska LATE! :) 16:00
kparal exactly midnight in bejing, if i see right 16:00
lili_ deep night :) 16:00
jlaska wwoods: adamw: you guys in lurk mode? 16:00
adamw morningh 16:00
* wwoods lurking, may need to leave early on an errand 16:01
jlaska adamw: wwoods: howdy gents 16:01
jlaska we've got a busy agenda today ... so I'm going to just start moving 16:01
jlaska feel free to stop me or slow me down if there any points missed 16:02
jlaska and again ... thanks for staying up late and joining us Liam :) 16:02
lili_ I am ok, :) 16:02
jlaska I'll be walking through the proposed agenda - https://www.redhat.com/archives/fedora-test-list/2009-October/msg00382.html 16:02
jlaska starting with ... 16:03
jlaska #topic Previous meeting follow-up 16:03
jlaska Oxf13 raised some concerns in the last meeting that QA was finding blocker bugs too late after the freeze 16:03
Oxf13 I'm here, sorry having some irc issues 16:04
jlaska Oxf13: hi there! 16:04
jlaska adamw has a clever+simple solution to scrubbing the blocker list ... just use the blocker bug history 16:04
jlaska (instead of a complicated bz boolean search) 16:04
jlaska #link https://bugzilla.redhat.com/show_activity.cgi?id=507678 16:04
jlaska if I can quote adamw from the meeting ... 16:05
jlaska #info "36 issues were marked as beta blockers prior to freeze, 16 after the freeze." -adamw 16:05
jlaska what I'm trying to find out is if there was significant delay in finding and escalating 16:05
Oxf13 brb 16:05
jlaska so far, only one bug on the blocker list has more then 2 days between filing and escalating 16:06
jlaska that's not bad ... imo 16:06
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:06
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
buggbot Bug https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=523862 urgent, low, ---, dledford, CLOSED RAWHIDE, mdadm craps at boot 16:07
* Viking-Ice sneaks in from one meeting to another.. 16:07
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
jlaska Viking-Ice: howdy 16:07
jlaska #info jlaska manually inspecting F12Beta change history to see if any trends / problems exist in how we escalate blocker bugs 16:08
jlaska Next up ... 16:08
jlaska * jlaska to investigate packaging of israwhidebroken.com for production instance 16:08
jlaska this was really easy, wwoods did the hard work already here 16:08
jlaska we can talk more about it in the autoqa section, but israwhidebroken.git already uses setuputils 16:09
jlaska so it was a simple matter of python setup.py bdist_rpm 16:09
jlaska Now I just need to follow through with wwoods idea of adding a "autoqa/front-ends/" directory to house this content 16:09
wwoods yeah that's easy enough 16:09
jlaska wwoods: once this next action item gets done ... I'll send updates that route ... 16:10
jlaska * jlaska to request autoqa-devel@ for autoqa development discussion and patch review 16:10
wwoods now that we know how to get it packaged/installed properly we make it a subpackage of autoqa if we like 16:10
jlaska #info autoqa-devel mailing list has been requested - https://fedorahosted.org/fedora-infrastructure/ticket/1733 16:10
jlaska wwoods: I _definitely_ would appreciate some patch review for anything I touch! 16:10
jlaska so I'd like to get my changes out to the list for comments/feedback 16:10
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
jlaska #help New mailing list requested for autoqa development discussion - see https://fedorahosted.org/fedora-infrastructure/ticket/1733 16:11
jlaska okay ... any other follow-up actions from last week that I missed? 16:12
jlaska if not ... I'll start with #2 on https://www.redhat.com/archives/fedora-test-list/2009-October/msg00382.html 16:12
jlaska #topic Beta test review 16:12
jlaska As we did for the Alpha, I'd like to spend a moment on the Beta 16:13
jlaska what worked, what didn't, what could be improved 16:13
jlaska lili_: thank you for sending out the test run summary 16:13
jlaska #link https://www.redhat.com/archives/fedora-test-list/2009-October/msg00303.html 16:13
jlaska lili_: do you have any thoughts to share on what worked well, or what you would like to see improved next time? 16:13
lili_ what I am thinking is how to complete the test cases that still did not complete on test results 16:14
jlaska lili_: so a way to get to 100% executed in the test matrix? 16:15
lili_ some cases have to run on some special hardware, like efi 16:15
jlaska #info Fedora 12 Beta Install test matrix - https://fedoraproject.org/wiki/Test_Results:Fedora_12_Beta_RC2_Install 16:15
lili_ at least to finish all the tire 2 test cases according to our test plan 16:16
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
Southern_Gentlem lili_, also look at http://spins.fedoraunity.org/Members/Southern_Gentleman/Fedora%2012%20%20beta%20TestMatrix as well 16:16
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
jlaska lili_: what if we run fewer tests? 16:16
lili_ that will reduce our quality? 16:17
jlaska excellent question to ask ... I'm not certain of the answer 16:18
Jeff_S that's quite hard to quantify 16:18
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
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:18
jlaska #info lili asked if reducing the number of test cases would reduce quality 16:19
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
jlaska lili_: have a look at Southern_Gentlem's matrix ... he has some interesting tests 16:20
jlaska Southern_Gentlem: would you be interested in seeing your tests become wiki test cases that we can both link to and use? 16:20
Southern_Gentlem fine with me 16:21
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:21
jlaska Southern_Gentlem: no sense in us duplicating effort if we can avoid it 16:22
adamw i think it's pretty overwhelming, but we've discussed before that it's not trivial to reduce it 16:23
adamw if we could get tricksy we could have a dynamically generated 'not-yet-completed tests' version of the matrix? 16:23
adamw which only shows the white boxes... 16:23
Oxf13 if only we had a test case management system 16:23
jlaska not something we want or need 16:24
jlaska adamw: you can sort the matrix now to get that ... but certainly not as dynamic as you suggest 16:24
adamw yes, if only we had a TCMS we could spend lots of time maintaining and debugging it instead of testing things! 16:24
jlaska I keep thinking there's a <buzzword> crowd source </buzzword> solution here if we could gather feedback ... something smolt-like 16:24
jlaska that's probably too out there and not anything short-term 16:24
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
Southern_Gentlem my test cases have come from testing re-spins which evolved over time 16: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
Oxf13 jlaska: yeah, when we have to invent and manage it ourselves you're right 16:25
Oxf13 it's really a shame that RHT has such resources and aren't willing to share 16:25
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:25
jlaska #info adam suggests creating links to a sorted list of "What's remaining for testing" in lili's emails 16:26
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
jlaska okay, so there are some ideas here to build on for the next release 16:27
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
jlaska I'll be annoying folks constantly for more of them ... so if ideas come, feel free to send to the list 16:27
jlaska Oxf13: actually running? they're running now 16:28
jlaska Oxf13: different topic, we can talk about that shortly 16:28
jlaska #info Possible improvement - integration between lili and Southern_Gentlem's test matrices 16:28
jlaska #info Possible improvement - including a link to "Remaining testing" when sending emails 16:28
jlaska anything else I missed? 16:29
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
wwoods having autoqa edit the wiki is technically possible and probably not that hard 16:29
Southern_Gentlem jlaska, on testing i see it as we want alot of duplication to test on as much hardware as possible 16:29
jlaska "Is _anaconda_ broken?" 16:29
Southern_Gentlem better to have several people sign off on one test than one 16:30
jlaska Southern_Gentlem: good point ... we benefit from breadth of hardware coverage here ... that's something to consider 16:30
jlaska #info Southern_Gentlem suggests having multiple testers provides better hardware diversity in testing 16:31
jlaska okay ... let's shift gears 16:31
Southern_Gentlem the only thing broken i have found was the nfs installs 16:31
jlaska Southern_Gentlem: yeah, I think kparal feels your pain there too :) 16:31
kparal right 16:31
Southern_Gentlem which i dont consider a blocker for beta 16:31
Oxf13 wait, nfs installs broken? 16:32
Oxf13 that'd be a neat trick since I seemed to have done a few around here during the freeze 16:32
* Oxf13 is confused 16:32
kparal https://bugzilla.redhat.com/show_bug.cgi?id=528537 16:32
jlaska Oxf13: no they're not broken ... but there are some issues around nfs installations 16:32
buggbot Bug 528537: medium, low, ---, steved, ASSIGNED, fails to get kickstart file over nfs. 16:32
Oxf13 ah, yeah, cobbler provides the nfs files over http 16:32
jlaska ks=nfs: and nfsiso= both had some trouble 16:32
jlaska lili_: anything else you wanted to share about the test matrix before we move on? 16:33
lili_ i am thinking whether our test cases need to optimize 16:34
lili_ you can move on, we can find some time to talk about this later 16:35
jlaska lili_: okay ... I think you might be on to something ... but I don't have any great ideas at the moment :( 16:36
jlaska if anyone has suggestions for optimizing the test runs ... please do contact lili_ 16:36
jlaska #topic AutoQA Updates from wwoods and kparal 16:36
jlaska wwoods and kparal, I've got you both on for some updates today 16:37
jlaska who wants to go first? 16:37
kparal let wwoods, he has some errand :) 16:37
wwoods heh 16:37
kparal if i remember it correctly 16:37
wwoods indeed 16:37
jlaska take us away calgo^W wwoods 16:38
wwoods let's see - we're still working on getting the production autoqa instance active 16:38
wwoods more news on that as it happens, naturally 16:38
wwoods I've given up on patching autotest to add info about the job ID to the tests as they run 16:39
wwoods far simpler just to write a small "how to find test results" document 16:39
wwoods rather than maintaining an invasive and complicated patch 16:39
wwoods so really all that's left to do for the israwhidebroken pilot is getting everything up in production 16:40
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
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:40
wwoods fair enough 16:41
wwoods so the next thing in the works is setting up a hook/watcher for koji 16:41
jlaska #info waiting on production hardware delivery 16:41
kparal i have seen you already started to work on that 16:41
wwoods yes - https://fedorahosted.org/autoqa/browser/hooks/post-koji-build/watch-koji-builds.py 16:41
wwoods it works basically like the other watchers, listing all new builds since the previous run 16:42
kparal will you be able to also get link to the old package? 16:42
kparal not just the new one? 16:42
wwoods yes, I have some example code to do that 16:42
kparal great 16:42
wwoods but that's not really the watcher's problem 16:42
wwoods (arguably) 16:42
wwoods anyway, yes, it's easy to get a list of previous released versions of a new package 16:42
wwoods we just need to figure out what data post-koji-build tests can expect/require 16:43
wwoods and then we'll have a new hook ready to run tests 16:43
kparal that's perfect, we can then try to hook up my script 16:43
wwoods "url of new package(s)" seems obvious, not sure what else. possibly "tags for new package" 16:43
wwoods if anyone has some test ideas and has a clear picture of what data the test would need to run 16:43
wwoods please let me know 16:44
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
wwoods note that all the current watcher does is print a list of builds 16:44
wwoods it doesn't run autoqa yet 16:44
wwoods need to define test requirements before we can complete the hook 16:44
* jlaska updates more info's 16:44
wwoods anyway I may just use package URL + tag 16:44
wwoods for the first implementation 16:44
wwoods and we'll move on from there. 16:45
wwoods that's about all I've got 16:45
jlaska #info Additional work needed on koji package watcher/hook - only prints list of builds, needs integration into autoqa 16:45
jlaska wwoods: cool, nice work 16:45
Oxf13 right as you design this think about the future with a message bus 16:46
wwoods ah, yes 16:46
wwoods the koji guys are working on a plugin system for the koji hub 16:46
Oxf13 all you're going to get on the bus is "build of $foo was completed for target $bar" 16:46
wwoods such that you can react to incoming events 16:46
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
Oxf13 the test would probably have to figure out what the previous thing was to compare against 16:46
wwoods and, say, send out a message on a bus saying "package $nvr tagged into $tag" 16:46
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
wwoods Oxf13: yep - that's exactly why I'm saying that code should go into the tests themselves rather than the watcher 16:47
wwoods it's the same code either way 16:47
Oxf13 mbonnet: well sure, I meant that we wouldn't provide info like "previous build" 16:47
kparal wwoods: only it can be duplicated in the tests 16:47
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
wwoods kparal: they can share a library 16:47
mbonnet Oxf13: right, since koji doesn't really have a good idea of what that means 16:47
wwoods as the rats_* tests do with rats.py 16:47
kparal wwoods: that's true, ok 16:48
Oxf13 and there will probably be 2 types of things autoqa would want to pick up on 16:48
Oxf13 A) a build completing, and B) a build being tagged 16:48
wwoods Oxf13: actually, no 16:48
Oxf13 since in the grand future, a build won't be tagged until /after/ the autoqa passes 16:48
wwoods it's simpler to just wait for the build to be tagged with -candidate or -raw or something 16:48
Oxf13 erm 16:48
wwoods and then run tests and move it to a different tag 16:48
Oxf13 we don't want to tag builds that are no good 16:48
wwoods we can tag them with other things 16:49
Oxf13 hence wanting testing inserted before the tag action 16:49
wwoods they can land in dist-funk-whatever-preqa 16:49
wwoods and then run the tests 16:49
Oxf13 ugh 16:49
Oxf13 is there reasoning for this? 16:49
wwoods mikem tells me that a) watching for untagged builds is problematic and b) tag operations are cheap 16:49
Oxf13 ok. 16:49
* kparal will be back in 30s 16:49
jlaska kparal: okay, you're up next 16:50
jlaska #info jkeating reminded to keep an eye towards future integration with the message bus 16:50
wwoods the idea is the same either way, we're just quibbling over what the original trigger will be 16:50
wwoods currently it's hard to trigger on untagged builds, later it might be easier 16:50
Oxf13 sure 16:50
wwoods doesn't really matter in the end, we can just pick whichever way we like 16:50
Oxf13 tagging them with something just generates more mail, complicates garbage collection, and complicates our build scripts 16:50
jlaska This seems like stuff we can iron out later, no? 16:51
Oxf13 yes 16:51
jlaska or do we need to setup a side-discussion? 16:51
* kparal is back 16:51
jlaska kparal: howabout on your end ... any autoqa updates? 16:52
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
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
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
kparal http://git.fedorahosted.org/git/autoqa.git?a=tree;f=tests/rpmguard 16:52
jlaska rpmguard at least makes for a better future icon! :) 16:52
jlaska #info #1 - name: the script for displaying important differences between rpms, originally called 'packagediff', was renamed to 'rpmguard' 16:53
kparal yes, rpmguard: http://cats-whisker.com/web/node/85 16:53
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
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
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:53
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
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
kparal And that's probably all the news from rpmguard's world. 16:54
jlaska kparal: I'm excited to see you able to make use of rpmfluff 16:55
jlaska sounds like a cool tool 16:55
kparal i have even created a first ticket for that tool:) https://fedorahosted.org/rpmfluff/report/1 16:55
jlaska #help if interested, help test rpmguard (using latest rpmdiff from svn) 16:55
jlaska nice work :) 16:56
jlaska wwoods or kparal, any other items not captured, or follow-up items for next week? 16:56
kparal nothing on my mind currently 16:57
jlaska feel free to make liberal use of #info and #action 16:57
jlaska okay gang, thanks for the progress updates 16:57
jlaska Next up ... hopefully we've kept Viking-Ice around for a bit here 16:57
jlaska #topic How_to_Debug_<component> Update from Viking-Ice 16:57
jlaska Viking-Ice: got a few minutes to share progress / questions on your wiki initiative? 16:57
Viking-Ice adamw: was looking into if it was doable to do this as a template 16:58
adamw unfortunately i never got time to look at it last week. fortunately, i delegated... 16:59
adamw <rjune> https://fedoraproject.org/wiki/How_to_debug_Dracut_problems2 16:59
adamw https://fedoraproject.org/wiki/Template:How_to_debug2 16:59
adamw It's a start, I'm assuming there's just too much in each variable 16:59
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
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
jlaska #info rjune assisted adamw in testing the use of a wiki template 16:59
jlaska #link https://fedoraproject.org/wiki/How_to_debug_Dracut_problems2 16:59
jlaska #link https://fedoraproject.org/wiki/Template:How_to_debug2 16:59
jlaska That looks darned good to me 17:00
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
jlaska that's what we've done with

Description

A brief description of the functionality being tested.


How to test

  1. Start here ...
  2. Next do this ...
  3. Finally click that

Expected Results

  1. Step #1 completes without error
  2. The system boots into runlevel 5
  3. Program completes with exit code 0


... I Don't see why we can't here
17:00
jlaska that format leaves plenty of room for embrace + extend 17:00
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
Viking-Ice fine if we can 17:00
Viking-Ice I'm by no means wiki expert.. 17:01
adamw so please don't let this stop you (anyone) working on revising pages to fit the new naming scheme / layout. 17:01
jlaska adamw: how will you know when you and rjune are done? 17:01
adamw jlaska: when we have something we're happy with we'll send it to the list, I think 17:01
adamw and if we get a template that's generally agreed upon we'll document its use in the Debugging category page 17:02
jlaska sounds like a plan 17:02
Viking-Ice so we should just rewrite those pages again? ( using the template ) 17:02
Viking-Ice instead of the current method of copy/paste the template 17:02
adamw Viking-Ice: not right now, that template isn't finalized i don't think 17:02
Viking-Ice ok 17:02
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:02
adamw sound good? 17:03
Viking-Ice yup ok 17:03
jlaska Viking-Ice: any other items you'd like to record / discuss today? 17:03
Viking-Ice nope nothing to share or discuss 17:04
adamw does anyone want to take an action item to go ahead and do the renaming? 17:04
adamw (if it's not been done already) 17:04
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
jlaska adamw: I can take that, that's just a ticket in to the wiki team no? 17:04
adamw no need, you can do it directly 17:04
jlaska sure, doesn't seem like a lot of pages 17:04
adamw there's a 'move' button for every wiki page that lets you rename it 17:04
jlaska yuppers 17:05
jlaska anyone else want it? 17:05
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
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:05
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:06
jlaska adamw: Viking-Ice you want me to include pages we didn't produce in the move? 17:07
jlaska e.g. Anaconda/BugReporting and "Reporting virt bugs" ? 17:07
jlaska alrighty ... lt's move to open discussion 17:08
adamw it may be nice to ask the people who created the pages first 17:08
jlaska adamw: roger 17:08
adamw but i'd envisage them being included in the end, if no-one complains 17:08
jlaska #info existing Debugging pages using older name scheme will need to be moved 17:08
jlaska #topic Open Discussion - <your topic here> 17:09
jlaska okay folks ... any topics to raise that weren't discussed already? 17:09
Oxf13 We're going to need extra eyes/fingers/whatever as we get crit-path tag requests for final 17:09
adamw is there a list to subscribe to to be notified of 'em? a list for new trac reports for releng? 17:10
Oxf13 there is the rel-eng@lists.fedorahosted.org list 17:10
Oxf13 also , rss feeds 17:10
adamw ah, rss sounds like win 17:10
jlaska #info Oxf13 asked for extra eyes/fingers as crit-path tag requests come in for final 17:10
jlaska Oxf13: is there a standard set of criteria that must be provided for a crit-path package update request? 17:10
jlaska e.g. link to bugzilla, link to patches, and an severity/impact statement? 17:11
Oxf13 there is no standard 17:11
jlaska and must exist on F12Blocker ? 17:11
Oxf13 we didn't set one for crit-path other than "somebody else will test it" 17:11
Viking-Ice jlaska: if we move pages should we rewrite them at the same time for the new layout ? 17:11
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
jlaska Viking-Ice: I believe the edit and the move are different operations 17:11
adamw Viking-Ice: yeah, you can do the rename without the rewrite. 17:12
adamw and vice versa. 17:12
adamw obviously doing both is the end goal, though. =) 17:12
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
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
adamw Oxf13: thanks, i'll play with it. 17:12
Viking-Ice Well yes but I was more thinking that we should rewrite them just delete the old one.. 17:13
Viking-Ice after rewrite ofcourse 17:13
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
jlaska Oxf13: oh okay, is there a template you ask requestors to follow? 17:13
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
* jlaska not up on all the details of this process 17:13
Oxf13 jlaska: if they use 'make tag-request' yes 17:13
* jlaska thanks adamw for the meetbot tag 17:14
adamw Oxf13: btw, i hadn't heard of that until it was randomly mentioned in a list post...where's it documented? 17:14
Oxf13 hadn't heard what? 17:14
Oxf13 'make tag-request' ? 17:14
adamw yeah 17:14
Oxf13 ah, so it just got created not too long ago, and was only available to rawhide users 17:15
Oxf13 so I announced it in email hopeing to get some testing on it and do some tweaking 17:15
Oxf13 I'm mostly happy with it though, so I wouldn't mind it finding its way into a wiki page 17:15
Oxf13 but I've been... distracted 17:15
mcepl Oxf13: https://fedoraproject.org/wiki/ReleaseEngineering/FinalFreezePolicy 17:15
Oxf13 mcepl: feel free to add it there 17:16
mcepl it is there 17:16
mcepl I put it there 17:16
Oxf13 ah it's at the bottom. 17:16
jlaska Oxf13: do you have any update on the download.fedora.devel.redhat.com and download.fedoraproject.org rawhide syncing? 17:16
Oxf13 that page could use some wiki/wordsmithing 17:16
Oxf13 jlaska: no... is it still bad? 17:16
jlaska Oxf13: I think ... it looks like our rats_install tests are still failing do to content out of sync 17:16
Oxf13 *grump* 17:16
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
jlaska #link https://fedorahosted.org/pipermail/autoqa-results/2009-October/001652.html 17:17
jlaska okay folks ... anything else to discuss today 17:17
jlaska or should we let lili_ sleep? :) 17:17
adamw mcepl: excellent, thanks 17:18
adamw jlaska: just one thing 17:18
jlaska adamw: sure, go for it 17:18
adamw jlaska and I have been working on the common bugs page 17:18
adamw #link https://fedoraproject.org/wiki/Common_F12_bugs 17:18
adamw we've more or less cleared the list of bugs already tagged to be included on it 17:18
lili_ :) 17:18
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
jlaska adamw: you give me credit for common_bugs? I've had a minor contribution 17:19
adamw oh hush with the modesty :) 17:19
jlaska #action jlaska - help clean out remaining promised Common_F12_Bugs 17:19
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
jlaska #link http://tinyurl.com/l4kma5 - Bugs needing Common_F12_Bugs documentation 17:20
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
jlaska adamw: great reminder, thanks adamw 17:20
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
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:21
jlaska #info talking points for Fedora 12 Beta awesome-ness - https://fedoraproject.org/wiki/F12_Beta_Announcement 17:22
jlaska right on 17:22
jlaska alright gang ... I think that does it for today 17:22
Southern_Gentlem i have found f12 beta to be fairly solid as far as the install process is going 17:22
adamw yeah, i think f12 beta is actually pretty awesome. i've signed off on final distribution releases that were worse. =) 17:23
jlaska thanks everyone for your time and to lili_ for _not_ sleeping 17:23
adamw night lili! 17:23
Southern_Gentlem except for the nfs issues it looks good 17:23
jlaska let's keep our vigilence going for the coming weeks ... still have an RC yet to land 17:23
jlaska #stopmeeting 17:23
jlaska #endmeeting 17:23
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:24
lili_ have a nice day,bye 17:25
jlaska Southern_Gentlem: thank you! Right now, lili uses rel-eng hosted tickets to track updates 17:25
jlaska nirik: did meetbot eat the minutes? 17:33
nirik jlaska: hum. ;( not sure what happened. 17:46
nirik jlaska: appears so. ;( Sorry about that... ;( 17:50
nirik jlaska: might be able to replay it in at some point. 17:50
jlaska nirik: oh, a replay would be helpful 17:53
zodbot Oxf13: Error: Can't start another meeting, one is in progress. 18:05
Oxf13 um. 18:05
Oxf13 #endmeeting 18:05
Oxf13 jlaska: can you do #endmeeting ? 18:05
Oxf13 nirik: the bot may be stuck 18:05
nirik oh, hang on. 18:06
nirik .addchair nirik 18:06
zodbot nirik: (addchair <channel> <network> <nick>) -- Add a nick as a chair to the meeting. 18:06
nirik .addchair #fedora-meeting nirik 18:06
zodbot nirik: (addchair <channel> <network> <nick>) -- Add a nick as a chair to the meeting. 18:06
jlaska #endmeeting 18:07
jlaska should I start meeting again? 18:07
jlaska #stopmeeting 18:07
zodbot jlaska: Error: Can't start another meeting, one is in progress. 18:07
nirik no, hang on. 18:07
Oxf13 who's the chair? 18:07
jlaska #endmeeting 18:07
jlaska should be me 18:07
nirik hum. 18:08
nirik frack. Xchat. ;( 18:08
jlaska #chair nirik 18:09
zodbot Current chairs: jlaska nirik 18:09
notting Oxf13: anything for today? 18:09
nirik #endmeeting 18:09

Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!

Retrieved from "https://fedoraproject.org/w/index.php?title=QA/Meetings/20091019&oldid=131016"