From Fedora Project Wiki

< QA‎ | Meetings

(Initial draft)
m (internal link cleaning)
 
(5 intermediate revisions by one other user not shown)
Line 2: Line 2:


People present (lines said)
People present (lines said)
* jlaska (135)
* Oxf13 (34)
* adamw (32)
* kparal (16)
* jskladan (11)
* wwoods (11)
* zodbot (3)
* pjones (2)
* Viking-Ice (1)
* jeff_hann (1)


Regrets:
Regrets:
Line 9: Line 20:


= Agenda =
= Agenda =
* [FIXME Proposed meeting agenda]
* [http://lists.fedoraproject.org/pipermail/test/2010-February/088478.html Proposed meeting agenda]
* [FIXME meetbot summary]
* [http://meetbot.fedoraproject.org/fedora-meeting/2010-02-15/fedora-qa.2010-02-15-16.00.html meetbot summary]


== Previous meeting follow-up ==
== Previous meeting follow-up ==
Line 36: Line 47:
=== IDEA - Live images for ''test compose'' milestone ===
=== IDEA - Live images for ''test compose'' milestone ===


[[User:Adamwill|Adamw]] proposed including live images with future 'test compose' milestones?
[[User:Adamwill|Adamw]] proposed including live images with future 'test compose' milestones.  adamw would like a single set of nightlies to be associated with each TC build and kept available in that TC directory during TC testing
 
After some debate, no conclusions were reached.  Jkeating felt providing nightly live images was not needed.


=== IDEA - Unique ISO image names for each drop  ===
=== IDEA - Unique ISO image names for each drop  ===


[[User:kparal|kparal]] proposed using unique ISO file names for each official test drop.
[[User:kparal|kparal]] proposed using unique ISO file names for each official test drop.  Kparal was concerned that since each the ISO file names from each test drop are the same, it might not be clear to testers what the ''latest'' images to use are.  After some discussion, Jkeating noted that the ISO file name produced comes from specific arguments used during the compose process and the current values are tightly integrated with the build process.
 
Jkeating noted that eventually, this information would be present in a future release engineering SOP (see [[Composing_Test_Composes]]).


== AutoQA project update ==
== AutoQA project update ==
Line 50: Line 65:


''Last week''
''Last week''
* Blogged about depcheck work - http://qa-rockstar.livejournal.com/9234.html
* Not much progress, wwoods was out sick for most of last week


''This week''
''This week''
Line 62: Line 77:
''Last week''
''Last week''
* Held design session last week with wwoods, kparal and jskladan (see [https://fedorahosted.org/pipermail/autoqa-devel/2010-February/000201.html recap])
* Held design session last week with wwoods, kparal and jskladan (see [https://fedorahosted.org/pipermail/autoqa-devel/2010-February/000201.html recap])
''This week''
* Continue research on other test frameworks handling of results
=== Beakerlib integration ===
* Owner - [[User:skladan]]
''Last week''
* kamil and I created a simple test, which demonstrates usage of beakerlib-based tests
* With help from Kamil, created a ''hello world'' beakerlib test and began the work of wrapping AutoQA/Autotest around it (see http://jskladan.fedorapeople.org/beakerlib_helloworld.tar)
''This week''
* we'll be trying to assimilate other tests this week - probably init script testing stuff - and look into some more complex uses


=== install automation ===
=== install automation ===
Line 69: Line 98:


''Last week''
''Last week''
* Reviewing options for booting ISO media while using a kickstart ([http://lists.fedoraproject.org/pipermail/virt/2010-February/001809.html
* Reviewing dvd install options
consulting] kvm autotest and virt teams)
* Sent [https://fedorahosted.org/pipermail/autoqa-devel/2010-February/000199.html summary of dvd install options] for review


''This week''
''This week''
* Attempt to implement ISO install method recommended by virt team
* Chinese new year, so no action expected.


=== packaging/deployment ===
=== packaging/deployment ===
Line 85: Line 114:
''This week''
''This week''
* I still don't have a final picture for what needs packaging.  I'd like to schedule some sit-down time with akurtakov (others welcome) to finalize the packaging wish-list.
* I still don't have a final picture for what needs packaging.  I'd like to schedule some sit-down time with akurtakov (others welcome) to finalize the packaging wish-list.
* Adamw suggested to start packaging a leaf-node dependency just to get the foot in the door


== Open discussion - <Your topic here> ==
== Open discussion - <Your topic here> ==
Line 105: Line 135:
= Action items =
= Action items =


* No action items


= IRC transcript =
= IRC transcript =
{|
|- id="t16:00:23"
! style="background-color: #407a40" | jlaska
| style="color: #407a40" | #startmeeting Fedora QA Meeting
|| [[#t16:00:23|16:00]]
|- id="t16:00:24"
! style="background-color: #42427e" | zodbot
| style="color: #42427e" | Meeting started Mon Feb 15 16:00:23 2010 UTC.  The chair is jlaska. Information about MeetBot at http://wiki.debian.org/MeetBot.
|| [[#t16:00:24|16:00]]
|- id="t16:00:26"
! style="background-color: #42427e" | zodbot
| style="color: #42427e" | Useful Commands: #action #agreed #halp #info #idea #link #topic.
|| [[#t16:00:26|16:00]]
|- id="t16:00:28"
! style="background-color: #407a40" | jlaska
| style="color: #407a40" | #meetingname fedora-qa
|| [[#t16:00:28|16:00]]
|- id="t16:00:29"
! style="background-color: #42427e" | zodbot
| style="color: #42427e" | The meeting name has been set to 'fedora-qa'
|| [[#t16:00:29|16:00]]
|- id="t16:00:40"
! style="background-color: #407a40" | jlaska
| style="color: #407a40" | #topic Gathering
|| [[#t16:00:40|16:00]]
|- id="t16:00:48"
| colspan="2" | * kparal raises up his hand
|| [[#t16:00:48|16:00]]
|- id="t16:00:49"
! style="background-color: #818144" | adamw
| style="color: #818144" | morning
|| [[#t16:00:49|16:00]]
|- id="t16:00:57"
! style="background-color: #854685" | jskladan
| style="color: #854685" | hello
|| [[#t16:00:57|16:00]]
|- id="t16:01:25"
! style="background-color: #407a40" | jlaska
| style="color: #407a40" | greetings folks
|| [[#t16:01:25|16:01]]
|- id="t16:01:37"
! style="background-color: #818144" | adamw
| style="color: #818144" | Software Engineer Barbie also says hi
|| [[#t16:01:37|16:01]]
|- id="t16:01:37"
! style="background-color: #818144" | adamw
| style="color: #818144" | http://www.engadget.com/2010/02/14/barbies-slides-into-the-cubical-becomes-a-computer-software-en/
|| [[#t16:01:37|16:01]]
|- id="t16:01:43"
! style="background-color: #407a40" | jlaska
| style="color: #407a40" | I believe maxamillion has a conflict today
|| [[#t16:01:43|16:01]]
|- id="t16:02:15"
! style="background-color: #407a40" | jlaska
| style="color: #407a40" | finally, some mainstream recognition! :)
|| [[#t16:02:15|16:02]]
|- id="t16:02:29"
! style="background-color: #818144" | adamw
| style="color: #818144" | looks like me on a good day!
|| [[#t16:02:29|16:02]]
|- id="t16:02:49"
! style="background-color: #407a40" | jlaska
| style="color: #407a40" | adamw: does it come with more accessories (external monitors, bluetooth keyboard(s) etc...)
|| [[#t16:02:49|16:02]]
|- id="t16:03:03"
! style="background-color: #818144" | adamw
| style="color: #818144" | this being barbie, all signs point to 'yes'
|| [[#t16:03:03|16:03]]
|- id="t16:04:19"
! style="background-color: #407a40" | jlaska
| style="color: #407a40" | alright ... let's get started.  hopefully wwoods, Viking-Ice and tk009 can join in as we go
|| [[#t16:04:19|16:04]]
|- id="t16:04:35"
! style="background-color: #407a40" | jlaska
| style="color: #407a40" | #topic Previous Meeting Review
|| [[#t16:04:35|16:04]]
|- id="t16:04:51"
! style="background-color: #407a40" | jlaska
| style="color: #407a40" | I've only captured 2 items from last week ...
|| [[#t16:04:51|16:04]]
|- id="t16:04:55"
! style="background-color: #407a40" | jlaska
| style="color: #407a40" | #info jlaska will follow-up w/ nirik after the meeting to setup zodbot feed watchers
|| [[#t16:04:55|16:04]]
|- id="t16:05:02"
! style="background-color: #407a40" | jlaska
| style="color: #407a40" | thanks nirik, we can check this off
|| [[#t16:05:02|16:05]]
|- id="t16:05:20"
! style="background-color: #407a40" | jlaska
| style="color: #407a40" | we have zodbot notification for any additions to the F13Alpha, F13Beta and F13Blocker bugs
|| [[#t16:05:20|16:05]]
|- id="t16:05:34"
! style="background-color: #407a40" | jlaska
| style="color: #407a40" | we might want to consider fedora-qa TRAC ticket additions as well
|| [[#t16:05:34|16:05]]
|- id="t16:05:49"
! style="background-color: #407a40" | jlaska
| style="color: #407a40" | #info completed ... IRC zodbot notification for any additions to the F13Alpha, F13Beta and F13Blocker bugs (thanks nirik)
|| [[#t16:05:49|16:05]]
|- id="t16:05:57"
! style="background-color: #407a40" | jlaska
| style="color: #407a40" | next up ...
|| [[#t16:05:57|16:05]]
|- id="t16:06:01"
! style="background-color: #407a40" | jlaska
| style="color: #407a40" | #info jlaska to work w/ poelstra to give 'release validation' spin to quality milestones
|| [[#t16:06:01|16:06]]
|- id="t16:06:20"
! style="background-color: #407a40" | jlaska
| style="color: #407a40" | This is completed as well ... I suggested a minor wording change (nothing crazy)
|| [[#t16:06:20|16:06]]
|- id="t16:06:44"
! style="background-color: #407a40" | jlaska
| style="color: #407a40" | the test milestones are no longer specific to install
|| [[#t16:06:44|16:06]]
|- id="t16:06:51"
! style="background-color: #407a40" | jlaska
| style="color: #407a40" | (e.g. Test Alpha 'Test Compose' and Test Alpha Candidate)
|| [[#t16:06:51|16:06]]
|- id="t16:06:59"
| colspan="2" | * Oxf13 is here, sorry
|| [[#t16:06:59|16:06]]
|- id="t16:07:03"
! style="background-color: #407a40" | jlaska
| style="color: #407a40" | Oxf13: welcome!
|| [[#t16:07:03|16:07]]
|- id="t16:07:19"
! style="background-color: #407a40" | jlaska
| style="color: #407a40" | #info completed, the wording around scheduled test milestones are no longer specific to install
|| [[#t16:07:19|16:07]]
|- id="t16:07:28"
! style="background-color: #407a40" | jlaska
| style="color: #407a40" | that's all I had to track from last week ... anything I missed?
|| [[#t16:07:28|16:07]]
|- id="t16:08:20"
! style="background-color: #407a40" | jlaska
| style="color: #407a40" | alright ... diving into the proposed agenda
|| [[#t16:08:20|16:08]]
|- id="t16:08:33"
! style="background-color: #407a40" | jlaska
| style="color: #407a40" | #topic Rawhide Acceptance Test #3
|| [[#t16:08:33|16:08]]
|- id="t16:08:57"
! style="background-color: #407a40" | jlaska
| style="color: #407a40" | Just a quick update on the last of 3 rawhide acceptance test (RAT) drops
|| [[#t16:08:57|16:08]]
|- id="t16:09:09"
! style="background-color: #407a40" | jlaska
| style="color: #407a40" | you probably saw the announcement ... so I'm just summarizing here
|| [[#t16:09:09|16:09]]
|- id="t16:09:24"
! style="background-color: #407a40" | jlaska
| style="color: #407a40" | #info RATS#3 test recap at http://lists.fedoraproject.org/pipermail/test/2010-February/088407.html
|| [[#t16:09:24|16:09]]
|- id="t16:09:51"
! style="background-color: #407a40" | jlaska
| style="color: #407a40" | This milestone helped flesh out a few patches against rats_install
|| [[#t16:09:51|16:09]]
|- id="t16:10:07"
! style="background-color: #407a40" | jlaska
| style="color: #407a40" | thanks wwoods for review feedback, I'll follow-up on those shortly
|| [[#t16:10:07|16:10]]
|- id="t16:10:40"
! style="background-color: #407a40" | jlaska
| style="color: #407a40" | I need to update the RATS watcher script to watch the new URL (see ticket#115) ... I don't have immediate plans to look into that
|| [[#t16:10:40|16:10]]
|- id="t16:10:48"
! style="background-color: #407a40" | jlaska
| style="color: #407a40" | so anyone with interest and time is welcome to pitch in
|| [[#t16:10:48|16:10]]
|- id="t16:11:07"
! style="background-color: #407a40" | jlaska
| style="color: #407a40" | as always, Oxf13 thanks for coordinating the drops with dlehman
|| [[#t16:11:07|16:11]]
|- id="t16:11:25"
! style="background-color: #407a40" | jlaska
| style="color: #407a40" | that's all I had on that ... let's dive into the Alpha ...
|| [[#t16:11:25|16:11]]
|- id="t16:11:35"
! style="background-color: #407a40" | jlaska
| style="color: #407a40" | #topic Alpha TC test status
|| [[#t16:11:35|16:11]]
|- id="t16:11:58"
! style="background-color: #407a40" | jlaska
| style="color: #407a40" | just a quick summary ... then onto some ideas raised by kparal and adamw
|| [[#t16:11:58|16:11]]
|- id="t16:12:27"
! style="background-color: #407a40" | jlaska
| style="color: #407a40" | #info F-13-Alpha-TC2 is available for testing
|| [[#t16:12:27|16:12]]
|- id="t16:12:41"
! style="background-color: #407a40" | jlaska
| style="color: #407a40" | #link [[QA:Fedora_13_Alpha_TC_Install_Test_Results]]
|| [[#t16:12:41|16:12]]
|- id="t16:12:45"
! style="background-color: #407a40" | jlaska
| style="color: #407a40" | #link [[QA:Fedora_13_Alpha_TC_Desktop_Test_Results]]
|| [[#t16:12:45|16:12]]
|- id="t16:12:57"
! style="background-color: #818144" | adamw
| style="color: #818144" | yay desktop testing
|| [[#t16:12:57|16:12]]
|- id="t16:13:02"
! style="background-color: #818144" | adamw
| style="color: #818144" | wait, now I actually have to do some
|| [[#t16:13:02|16:13]]
|- id="t16:13:03"
! style="background-color: #407a40" | jlaska
| style="color: #407a40" | woot!
|| [[#t16:13:03|16:13]]
|- id="t16:13:06"
! style="background-color: #818144" | adamw
| style="color: #818144" | whose stupid idea was this?
|| [[#t16:13:06|16:13]]
|- id="t16:13:08"
! style="background-color: #407a40" | jlaska
| style="color: #407a40" | adamw: deatils deatils
|| [[#t16:13:08|16:13]]
|- id="t16:13:16"
! style="background-color: #407a40" | jlaska
| style="color: #407a40" | details too :)
|| [[#t16:13:16|16:13]]
|- id="t16:13:49"
! style="background-color: #407a40" | jlaska
| style="color: #407a40" | so first note I have here was from adamw ...
|| [[#t16:13:49|16:13]]
|- id="t16:14:15"
! style="background-color: #407a40" | jlaska
| style="color: #407a40" | #topic IDEA - publish live images along with 'test composes'
|| [[#t16:14:15|16:14]]
|- id="t16:14:31"
! style="background-color: #407a40" | jlaska
| style="color: #407a40" | adamw: you raised this last week, I put this on the agenda so we wouldn't forget
|| [[#t16:14:31|16:14]]
|- id="t16:15:33"
| colspan="2" | * Viking-Ice sneaks in..
|| [[#t16:15:33|16:15]]
|- id="t16:15:41"
! style="background-color: #407a40" | jlaska
| style="color: #407a40" | Oxf13 I believe live images are provided for the release candidate drops (alpha, beta and final) ... with the new focus around desktop validation, are we able to provide them for 'test compose' as well?
|| [[#t16:15:41|16:15]]
|- id="t16:15:50"
! style="background-color: #407a40" | jlaska
| style="color: #407a40" | Viking-Ice: welcome!
|| [[#t16:15:50|16:15]]
|- id="t16:16:13"
! style="background-color: #488888" | Oxf13
| style="color: #488888" | jlaska: well, we already make live images nightly
|| [[#t16:16:13|16:16]]
|- id="t16:16:19"
! style="background-color: #407a40" | jlaska
| style="color: #407a40" | we've historically relied on the nightly images ... but depending on the state of the repo ... we can go days without any live images
|| [[#t16:16:19|16:16]]
|- id="t16:16:21"
! style="background-color: #488888" | Oxf13
| style="color: #488888" | duplicating that work would be, well, duplicated work
|| [[#t16:16:21|16:16]]
|- id="t16:16:34"
! style="background-color: #488888" | Oxf13
| style="color: #488888" | if the repo is busted for making the nightly images, how am I supposed to make them?
|| [[#t16:16:34|16:16]]
|- id="t16:16:36"
| colspan="2" | * jeff_hann here, sorry I'm late
|| [[#t16:16:36|16:16]]
|- id="t16:16:39"
| colspan="2" | * wwoods appears
|| [[#t16:16:39|16:16]]
|- id="t16:16:43"
! style="background-color: #818144" | adamw
| style="color: #818144" | as I said in IRC, there's no need for a separate image generation process
|| [[#t16:16:43|16:16]]
|- id="t16:16:44"
! style="background-color: #407a40" | jlaska
| style="color: #407a40" | wwoods: jeff_hann hey gang
|| [[#t16:16:44|16:16]]
|- id="t16:16:53"
! style="background-color: #818144" | adamw
| style="color: #818144" | just take the nightlies from the appropriate day and stick them in the TC directory
|| [[#t16:16:53|16:16]]
|- id="t16:17:06"
! style="background-color: #818144" | adamw
| style="color: #818144" | just want to have a single 'approved' live image that everyone's working from
|| [[#t16:17:06|16:17]]
|- id="t16:17:14"
! style="background-color: #818144" | adamw
| style="color: #818144" | again, if it's too much work, it's not vital.
|| [[#t16:17:14|16:17]]
|- id="t16:17:15"
! style="background-color: #488888" | Oxf13
| style="color: #488888" | ...
|| [[#t16:17:15|16:17]]
|- id="t16:17:31"
! style="background-color: #407a40" | jlaska
| style="color: #407a40" | yeah, doesn't matter to me which images we use ... just that we have images to test with
|| [[#t16:17:31|16:17]]
|- id="t16:17:33"
! style="background-color: #488888" | Oxf13
| style="color: #488888" | pointing to the live isos at the same time you point to the TC doesn't work?
|| [[#t16:17:33|16:17]]
|- id="t16:17:44"
! style="background-color: #818144" | adamw
| style="color: #818144" | Oxf13: no, because anyone who reads it the next day can't use the same image
|| [[#t16:17:44|16:17]]
|- id="t16:17:53"
! style="background-color: #818144" | adamw
| style="color: #818144" | but they can still get the right TC images
|| [[#t16:17:53|16:17]]
|- id="t16:17:55"
! style="background-color: #488888" | Oxf13
| style="color: #488888" | I suppose I could just make hardlinks
|| [[#t16:17:55|16:17]]
|- id="t16:18:11"
! style="background-color: #818144" | adamw
| style="color: #818144" | Oxf13: the nightlies don't stick around, they get wiped and regenerated every day
|| [[#t16:18:11|16:18]]
|- id="t16:18:21"
! style="background-color: #407a40" | jlaska
| style="color: #407a40" | would kparal's suggestion of always keeping around the previous successful live image build solve this?
|| [[#t16:18:21|16:18]]
|- id="t16:18:31"
! style="background-color: #488888" | Oxf13
| style="color: #488888" | hardlinks would solve this
|| [[#t16:18:31|16:18]]
|- id="t16:18:38"
! style="background-color: #818144" | adamw
| style="color: #818144" | no, because you still have the problem if the next build is successful
|| [[#t16:18:38|16:18]]
|- id="t16:18:52"
! style="background-color: #818144" | adamw
| style="color: #818144" | it's not that i'm worried a later build won't be 'successful' and no one will be able to test
|| [[#t16:18:52|16:18]]
|- id="t16:19:02"
! style="background-color: #818144" | adamw
| style="color: #818144" | just worried that people would be testing with different stuff, leading to possibly confusing results...
|| [[#t16:19:02|16:19]]
|- id="t16:19:33"
! style="background-color: #818144" | adamw
| style="color: #818144" | (tester A tests with 2010-02-15 and feature B is broken but feature C works, tester D tests with 2010-02-16 and gets the opposite result, world goes 'huh'?)
|| [[#t16:19:33|16:19]]
|- id="t16:20:01"
! style="background-color: #407a40" | jlaska
| style="color: #407a40" | seems like a reasonable request
|| [[#t16:20:01|16:20]]
|- id="t16:20:05"
! style="background-color: #8c4a4a" | kparal
| style="color: #8c4a4a" | nicely said :)
|| [[#t16:20:05|16:20]]
|- id="t16:20:33"
! style="background-color: #818144" | adamw
| style="color: #818144" | Oxf13: yeah, a hardlink should do it I guess.
|| [[#t16:20:33|16:20]]
|- id="t16:20:41"
! style="background-color: #407a40" | jlaska
| style="color: #407a40" | so the issue is making it clearer what people should be testing with ... instead of providing a URL to a directory that may or may not contain images?
|| [[#t16:20:41|16:20]]
|- id="t16:20:57"
! style="background-color: #488888" | Oxf13
| style="color: #488888" | well
|| [[#t16:20:57|16:20]]
|- id="t16:21:03"
! style="background-color: #818144" | adamw
| style="color: #818144" | not just that. as I said, at present, it's not just an information issue
|| [[#t16:21:03|16:21]]
|- id="t16:21:05"
! style="background-color: #488888" | Oxf13
| style="color: #488888" | there is the problem of testing the static image instead of the next nightly
|| [[#t16:21:05|16:21]]
|- id="t16:21:12"
! style="background-color: #488888" | Oxf13
| style="color: #488888" | because the next nightly is what's going to be in the release
|| [[#t16:21:12|16:21]]
|- id="t16:21:25"
! style="background-color: #488888" | Oxf13
| style="color: #488888" | so testing what's older isn't all that useful, if the newer is broken
|| [[#t16:21:25|16:21]]
|- id="t16:21:28"
! style="background-color: #818144" | adamw
| style="color: #818144" | Oxf13: but that applies equally to the non-live bits
|| [[#t16:21:28|16:21]]
|- id="t16:21:38"
! style="background-color: #488888" | Oxf13
| style="color: #488888" | adamw: except we don't generate the non-live bits every day
|| [[#t16:21:38|16:21]]
|- id="t16:21:40"
! style="background-color: #818144" | adamw
| style="color: #818144" | the test compose isn't what's going to be in the release either
|| [[#t16:21:40|16:21]]
|- id="t16:21:44"
! style="background-color: #488888" | Oxf13
| style="color: #488888" | so we don't have the opportunity to test the newer bits
|| [[#t16:21:44|16:21]]
|- id="t16:22:08"
! style="background-color: #818144" | adamw
| style="color: #818144" | still, it's difficult to do consistent testing and be sure about the results if different testers are testing different bits.
|| [[#t16:22:08|16:22]]
|- id="t16:22:23"
! style="background-color: #488888" | Oxf13
| style="color: #488888" | adamw: but we're still in "things change daily"
|| [[#t16:22:23|16:22]]
|- id="t16:22:26"
! style="background-color: #488888" | Oxf13
| style="color: #488888" | mode
|| [[#t16:22:26|16:22]]
|- id="t16:22:34"
! style="background-color: #488888" | Oxf13
| style="color: #488888" | we haven't stopped yet
|| [[#t16:22:34|16:22]]
|- id="t16:22:46"
! style="background-color: #488888" | Oxf13
| style="color: #488888" | these TC images aren't us stopping
|| [[#t16:22:46|16:22]]
|- id="t16:23:03"
! style="background-color: #488888" | Oxf13
| style="color: #488888" | they're just a snapshot of something we haven't yet produced this cycle to see what might be broken
|| [[#t16:23:03|16:23]]
|- id="t16:23:15"
! style="background-color: #488888" | Oxf13
| style="color: #488888" | in those specific things we don't always produce
|| [[#t16:23:15|16:23]]
|- id="t16:23:20"
! style="background-color: #407a40" | jlaska
| style="color: #407a40" | so adamw, want to summarize what QA is requesting?
|| [[#t16:23:20|16:23]]
|- id="t16:23:31"
! style="background-color: #818144" | adamw
| style="color: #818144" | i think we've wasted enough time already and should just move on
|| [[#t16:23:31|16:23]]
|- id="t16:23:40"
! style="background-color: #407a40" | jlaska
| style="color: #407a40" | yup ... summarize, next steps and we'll move on
|| [[#t16:23:40|16:23]]
|- id="t16:23:54"
| colspan="2" | * jlaska suggests excessive use of #info
|| [[#t16:23:54|16:23]]
|- id="t16:23:56"
! style="background-color: #818144" | adamw
| style="color: #818144" | if it takes this much debate to get it done it's probably not worth doing
|| [[#t16:23:56|16:23]]
|- id="t16:24:34"
! style="background-color: #818144" | adamw
| style="color: #818144" | #info adamw would like a single set of nightlies to be associated with each TC build and kept available in that TC directory during TC testing
|| [[#t16:24:34|16:24]]
|- id="t16:24:41"
! style="background-color: #818144" | adamw
| style="color: #818144" | #info oxf13 doesn't believe it's necessary
|| [[#t16:24:41|16:24]]
|- id="t16:24:43"
! style="background-color: #818144" | adamw
| style="color: #818144" | next topic.
|| [[#t16:24:43|16:24]]
|- id="t16:25:17"
! style="background-color: #407a40" | jlaska
| style="color: #407a40" | alrighty ... next up, I noted a topic from kparal.  But kparal and Oxf13 may have discussed this already
|| [[#t16:25:17|16:25]]
|- id="t16:25:21"
! style="background-color: #488888" | Oxf13
| style="color: #488888" | more like counterproductive to testing the bits that will be in the release.
|| [[#t16:25:21|16:25]]
|- id="t16:25:27"
! style="background-color: #8c4a4a" | kparal
| style="color: #8c4a4a" | I had almost the same question, this time about Alpha TC naming
|| [[#t16:25:27|16:25]]
|- id="t16:25:31"
! style="background-color: #407a40" | jlaska
| style="color: #407a40" | Oxf13: it's something QA is asking for
|| [[#t16:25:31|16:25]]
|- id="t16:25:36"
! style="background-color: #407a40" | jlaska
| style="color: #407a40" | I don't think it's counterproductive
|| [[#t16:25:36|16:25]]
|- id="t16:25:49"
! style="background-color: #407a40" | jlaska
| style="color: #407a40" | we'll follow this up in a ticket after the meeting
|| [[#t16:25:49|16:25]]
|- id="t16:25:55"
! style="background-color: #407a40" | jlaska
| style="color: #407a40" | #topic IDEA - Unique ISO image names for each drop
|| [[#t16:25:55|16:25]]
|- id="t16:26:03"
! style="background-color: #407a40" | jlaska
| style="color: #407a40" | kparal: what's the latest
|| [[#t16:26:03|16:26]]
|- id="t16:26:19"
! style="background-color: #8c4a4a" | kparal
| style="color: #8c4a4a" | well currently all TC iso's are named the same as the final Alpha iso
|| [[#t16:26:19|16:26]]
|- id="t16:26:34"
! style="background-color: #8c4a4a" | kparal
| style="color: #8c4a4a" | Oxf13 replied: by not naming the isos etc the same for TC and the alpha release, we risk missing some bug in the behavior of Anaconda and the release name/number
|| [[#t16:26:34|16:26]]
|- id="t16:27:16"
! style="background-color: #407a40" | jlaska
| style="color: #407a40" | you may have already discussed, but I wasn't clear on how the ISO file names are related to testing itself, was that cleared up?
|| [[#t16:27:16|16:27]]
|- id="t16:27:36"
! style="background-color: #8c4a4a" | kparal
| style="color: #8c4a4a" | I had similar concerns as adamw, people would be testing something other than we expect. or they might suppose they already have the F13 Alpha final iso (it's called like that, isn't it?), but they won't
|| [[#t16:27:36|16:27]]
|- id="t16:27:52"
! style="background-color: #4b904b" | pjones
| style="color: #4b904b" | kparal: Is there some reason to believe we're likely to have that kind of bug?
|| [[#t16:27:52|16:27]]
|- id="t16:28:19"
! style="background-color: #4b904b" | pjones
| style="color: #4b904b" | considering that we change the names for every release and haven't been having issues with it...
|| [[#t16:28:19|16:28]]
|- id="t16:28:33"
! style="background-color: #407a40" | jlaska
| style="color: #407a40" | we have people downloading the old ISO's a lot
|| [[#t16:28:33|16:28]]
|- id="t16:28:38"
! style="background-color: #8c4a4a" | kparal
| style="color: #8c4a4a" | well, I wasn't sure why the names are not simply unique
|| [[#t16:28:38|16:28]]
|- id="t16:28:44"
! style="background-color: #407a40" | jlaska
| style="color: #407a40" | normally, we have them validate the CHECKSUMS
|| [[#t16:28:44|16:28]]
|- id="t16:29:04"
! style="background-color: #488888" | Oxf13
| style="color: #488888" | not only that, but the TC stuff is on a completely different mirror system
|| [[#t16:29:04|16:29]]
|- id="t16:29:10"
! style="background-color: #8c4a4a" | kparal
| style="color: #8c4a4a" | so the Oxf13's explanation is above. I didn't know about anaconda issues, then I suppose it makes more sense
|| [[#t16:29:10|16:29]]
|- id="t16:29:13"
! style="background-color: #488888" | Oxf13
| style="color: #488888" | we can't really protect against stupid people.
|| [[#t16:29:13|16:29]]
|- id="t16:29:36"
! style="background-color: #488888" | Oxf13
| style="color: #488888" | buildinstall does do things with version and product which does change anaconda behaviour
|| [[#t16:29:36|16:29]]
|- id="t16:30:23"
! style="background-color: #4d4d93" | wwoods
| style="color: #4d4d93" | is there a TC# in the metadata anywhere? It'd be simplest to say "current test candidate is TC7" and then if .treeinfo says test-candidate = 6..
|| [[#t16:30:23|16:30]]
|- id="t16:30:28"
! style="background-color: #488888" | Oxf13
| style="color: #488888" | of course, this is one of the dangers of opening pre-release test isos up to more people
|| [[#t16:30:28|16:30]]
|- id="t16:30:36"
! style="background-color: #4d4d93" | wwoods
| style="color: #4d4d93" | but I don't really want to add new data if we don't have to. timestamps work, but people always get confused
|| [[#t16:30:36|16:30]]
|- id="t16:30:38"
! style="background-color: #488888" | Oxf13
| style="color: #488888" | you risk more people getting them who won't use them responsibly
|| [[#t16:30:38|16:30]]
|- id="t16:30:49"
! style="background-color: #488888" | Oxf13
| style="color: #488888" | wwoods: no
|| [[#t16:30:49|16:30]]
|- id="t16:30:56"
! style="background-color: #407a40" | jlaska
| style="color: #407a40" | Oxf13: I don' think there is bad intent for the images
|| [[#t16:30:56|16:30]]
|- id="t16:31:01"
! style="background-color: #488888" | Oxf13
| style="color: #488888" | wwoods: it's at the top of the URL, but from that point down, by design, it looks exactly like the Alpha would
|| [[#t16:31:01|16:31]]
|- id="t16:31:18"
! style="background-color: #488888" | Oxf13
| style="color: #488888" | jlaska: I don't mean malintent, I mean ignorance
|| [[#t16:31:18|16:31]]
|- id="t16:31:18"
! style="background-color: #407a40" | jlaska
| style="color: #407a40" | just looking for ways to make sure we are doing what's reasonable to make sure people know they are using the latest test images
|| [[#t16:31:18|16:31]]
|- id="t16:31:22"
! style="background-color: #407a40" | jlaska
| style="color: #407a40" | okay
|| [[#t16:31:22|16:31]]
|- id="t16:31:44"
! style="background-color: #8c4a4a" | kparal
| style="color: #8c4a4a" | I think we can move on
|| [[#t16:31:44|16:31]]
|- id="t16:31:48"
! style="background-color: #407a40" | jlaska
| style="color: #407a40" | kparal: Oxf13: so in summary the filename used for the ISO image files is tightly coupled to the whole build process?
|| [[#t16:31:48|16:31]]
|- id="t16:31:56"
! style="background-color: #488888" | Oxf13
| style="color: #488888" | jlaska: yes
|| [[#t16:31:56|16:31]]
|- id="t16:32:07"
! style="background-color: #407a40" | jlaska
| style="color: #407a40" | ah okay, not something I knew about
|| [[#t16:32:07|16:32]]
|- id="t16:32:17"
! style="background-color: #407a40" | jlaska
| style="color: #407a40" | probably one of the new SOPs has this listed
|| [[#t16:32:17|16:32]]
|- id="t16:32:22"
! style="background-color: #407a40" | jlaska
| style="color: #407a40" | [[Composing_test_images]] ?
|| [[#t16:32:22|16:32]]
|- id="t16:32:27"
! style="background-color: #488888" | Oxf13
| style="color: #488888" | the input to the compose process drives the name of the iso, I don't manually make the isos and pick a new name each time
|| [[#t16:32:27|16:32]]
|- id="t16:33:00"
! style="background-color: #488888" | Oxf13
| style="color: #488888" | jlaska: probably Composing_Test_Composes once we make that
|| [[#t16:33:00|16:33]]
|- id="t16:33:15"
! style="background-color: #407a40" | jlaska
| style="color: #407a40" | Oxf13: ah sweet, thanks
|| [[#t16:33:15|16:33]]
|- id="t16:33:33"
! style="background-color: #407a40" | jlaska
| style="color: #407a40" | alrighty, kparal anything else to discuss here, otherwise we'll dive into AutoQA
|| [[#t16:33:33|16:33]]
|- id="t16:33:43"
! style="background-color: #488888" | Oxf13
| style="color: #488888" | test_images doesn't have any isos produced (beyond boot.iso)
|| [[#t16:33:43|16:33]]
|- id="t16:34:11"
! style="background-color: #8c4a4a" | kparal
| style="color: #8c4a4a" | we can go on
|| [[#t16:34:11|16:34]]
|- id="t16:34:20"
! style="background-color: #407a40" | jlaska
| style="color: #407a40" | alrighty
|| [[#t16:34:20|16:34]]
|- id="t16:34:23"
! style="background-color: #407a40" | jlaska
| style="color: #407a40" | #topic AutoQA - depcheck update
|| [[#t16:34:23|16:34]]
|- id="t16:34:37"
! style="background-color: #407a40" | jlaska
| style="color: #407a40" | wwoods: you have the mic ... any updates or milestones to share?
|| [[#t16:34:37|16:34]]
|- id="t16:36:29"
! style="background-color: #407a40" | jlaska
| style="color: #407a40" | wwoods: we can come back to this later if you prefer?
|| [[#t16:36:29|16:36]]
|- id="t16:37:19"
! style="background-color: #407a40" | jlaska
| style="color: #407a40" | alright ... moving on to resultsdb ...
|| [[#t16:37:19|16:37]]
|- id="t16:37:30"
! style="background-color: #407a40" | jlaska
| style="color: #407a40" | #topic AutoQA - resultsdb discussion
|| [[#t16:37:30|16:37]]
|- id="t16:38:00"
! style="background-color: #407a40" | jlaska
| style="color: #407a40" | kparal, wwoods or jskladan, anything to add here?
|| [[#t16:38:00|16:38]]
|- id="t16:38:26"
! style="background-color: #8c4a4a" | kparal
| style="color: #8c4a4a" | well I would just mention that we had a small QA team discussion over phone
|| [[#t16:38:26|16:38]]
|- id="t16:38:35"
! style="background-color: #8c4a4a" | kparal
| style="color: #8c4a4a" | and the results are available in autoqa-devel ML
|| [[#t16:38:35|16:38]]
|- id="t16:38:43"
| colspan="2" | * wwoods was afk a sec, deferring to kparal for the moment
|| [[#t16:38:43|16:38]]
|- id="t16:38:46"
! style="background-color: #407a40" | jlaska
| style="color: #407a40" | #link https://fedorahosted.org/pipermail/autoqa-devel/2010-February/000201.html
|| [[#t16:38:46|16:38]]
|- id="t16:38:51"
! style="background-color: #407a40" | jlaska
| style="color: #407a40" | wwoods: okay
|| [[#t16:38:51|16:38]]
|- id="t16:39:08"
! style="background-color: #8c4a4a" | kparal
| style="color: #8c4a4a" | we are currently studying other projects, how they define their results database, etc
|| [[#t16:39:08|16:39]]
|- id="t16:39:24"
! style="background-color: #8c4a4a" | kparal
| style="color: #8c4a4a" | so any input can be sent to autoqa-devel
|| [[#t16:39:24|16:39]]
|- id="t16:40:09"
! style="background-color: #8c4a4a" | kparal
| style="color: #8c4a4a" | that's all I suppose
|| [[#t16:40:09|16:40]]
|- id="t16:40:30"
! style="background-color: #407a40" | jlaska
| style="color: #407a40" | kparal: okay, thanks for the update
|| [[#t16:40:30|16:40]]
|- id="t16:40:54"
! style="background-color: #407a40" | jlaska
| style="color: #407a40" | #topic AutoQA - beakerlib
|| [[#t16:40:54|16:40]]
|- id="t16:40:54"
! style="background-color: #4d4d93" | wwoods
| style="color: #4d4d93" | the current notion - if memory serves - is that we want to provide one unified resultsdb that al the autoqa tests can use to report (somewhat simplified) results
|| [[#t16:40:54|16:40]]
|- id="t16:41:21"
! style="background-color: #4d4d93" | wwoods
| style="color: #4d4d93" | which will give us one place to view all test results - and ideally a few nice views of that data.
|| [[#t16:41:21|16:41]]
|- id="t16:41:36"
! style="background-color: #407a40" | jlaska
| style="color: #407a40" | #topic AutoQA - resultsdb discussion
|| [[#t16:41:36|16:41]]
|- id="t16:42:07"
! style="background-color: #407a40" | jlaska
| style="color: #407a40" | #info we want to provide one unified resultsdb that all the autoqa tests can use to report (somewhat simplified) results
|| [[#t16:42:07|16:42]]
|- id="t16:42:11"
! style="background-color: #407a40" | jlaska
| style="color: #407a40" | one sec ... meeting tags
|| [[#t16:42:11|16:42]]
|- id="t16:42:34"
! style="background-color: #407a40" | jlaska
| style="color: #407a40" | #info had a small QA team discussion over phone last week (results on autoqa-devel ML)
|| [[#t16:42:34|16:42]]
|- id="t16:42:34"
! style="background-color: #4d4d93" | wwoods
| style="color: #4d4d93" | I think we had some example views we wanted to see - test results for a given package, test results for a given installable tree, all test results for package builds / updates for a given day, etc.
|| [[#t16:42:34|16:42]]
|- id="t16:42:57"
! style="background-color: #4d4d93" | wwoods
| style="color: #4d4d93" | if you can think of a good use case you'd like - a specific view of the autoqa results data - please let us know
|| [[#t16:42:57|16:42]]
|- id="t16:43:29"
! style="background-color: #407a40" | jlaska
| style="color: #407a40" | nice, thanks wwoods and kparal
|| [[#t16:43:29|16:43]]
|- id="t16:43:29"
! style="background-color: #4d4d93" | wwoods
| style="color: #4d4d93" | further discussion will be on autoqa-devel.
|| [[#t16:43:29|16:43]]
|- id="t16:43:49"
! style="background-color: #4d4d93" | wwoods
| style="color: #4d4d93" | oh, and as for depcheck: no progress, owing to the fact that I was out of the office and then sick all last week
|| [[#t16:43:49|16:43]]
|- id="t16:44:01"
! style="background-color: #407a40" | jlaska
| style="color: #407a40" | status - plague :(
|| [[#t16:44:01|16:44]]
|- id="t16:44:14"
! style="background-color: #407a40" | jlaska
| style="color: #407a40" | #topic AutoQA - beakerlib
|| [[#t16:44:14|16:44]]
|- id="t16:44:29"
! style="background-color: #854685" | jskladan
| style="color: #854685" | ok, time for me to speak, i suppose :)
|| [[#t16:44:29|16:44]]
|- id="t16:44:31"
! style="background-color: #407a40" | jlaska
| style="color: #407a40" | Adding a new topic here for the work jskladan and kparal have been looking into around beakerlib
|| [[#t16:44:31|16:44]]
|- id="t16:44:45"
! style="background-color: #407a40" | jlaska
| style="color: #407a40" | any updates or problems you are experiencing?
|| [[#t16:44:45|16:44]]
|- id="t16:45:15"
! style="background-color: #854685" | jskladan
| style="color: #854685" | well, idk if all af you are familiar with beakerlib
|| [[#t16:45:15|16:45]]
|- id="t16:45:34"
! style="background-color: #407a40" | jlaska
| style="color: #407a40" | #link https://fedorahosted.org/beakerlib/
|| [[#t16:45:34|16:45]]
|- id="t16:46:02"
! style="background-color: #854685" | jskladan
| style="color: #854685" | its a set of libraries which RHEL guys use for writing automated tests
|| [[#t16:46:02|16:46]]
|- id="t16:46:24"
! style="background-color: #854685" | jskladan
| style="color: #854685" | so we'd like to reuse those in out testing system (autoqa)
|| [[#t16:46:24|16:46]]
|- id="t16:47:06"
! style="background-color: #854685" | jskladan
| style="color: #854685" | today kamil and me created a simple test, which demonstrates usage of beakerlib-based tests
|| [[#t16:47:06|16:47]]
|- id="t16:47:17"
! style="background-color: #854685" | jskladan
| style="color: #854685" | #link http://jskladan.fedorapeople.org/beakerlib_helloworld.tar
|| [[#t16:47:17|16:47]]
|- id="t16:47:46"
! style="background-color: #854685" | jskladan
| style="color: #854685" | it's nothing fancy - in fact, it only makes sure, that you have beakerlib installed, and then runs the test itself
|| [[#t16:47:46|16:47]]
|- id="t16:47:50"
! style="background-color: #407a40" | jlaska
| style="color: #407a40" | nice, using the provided beakerlib vim syntax highlight! :)
|| [[#t16:47:50|16:47]]
|- id="t16:48:06"
! style="background-color: #407a40" | jlaska
| style="color: #407a40" | rlAssertRpm "setup"
|| [[#t16:48:06|16:48]]
|- id="t16:48:06"
! style="background-color: #407a40" | jlaska
| style="color: #407a40" | rlAssertExists "/etc/passwd"
|| [[#t16:48:06|16:48]]
|- id="t16:48:06"
! style="background-color: #407a40" | jlaska
| style="color: #407a40" | rlAssertGrep "root" "/etc/passwd"
|| [[#t16:48:06|16:48]]
|- id="t16:48:08"
! style="background-color: #407a40" | jlaska
| style="color: #407a40" | cool
|| [[#t16:48:08|16:48]]
|- id="t16:48:46"
! style="background-color: #854685" | jskladan
| style="color: #854685" | and of course stores the report produced by beakerlib in the directory for autotest-lib result files
|| [[#t16:48:46|16:48]]
|- id="t16:49:56"
! style="background-color: #854685" | jskladan
| style="color: #854685" | we'll be trying to assimilate other tests this week - probably init script testing stuff - and look into some more complex uses
|| [[#t16:49:56|16:49]]
|- id="t16:50:17"
! style="background-color: #407a40" | jlaska
| style="color: #407a40" | this is great news, it's moving along faster than I had expected
|| [[#t16:50:17|16:50]]
|- id="t16:50:22"
! style="background-color: #407a40" | jlaska
| style="color: #407a40" | nice work :)
|| [[#t16:50:22|16:50]]
|- id="t16:50:30"
! style="background-color: #854685" | jskladan
| style="color: #854685" | so that's about it for now - if kamil does not have anything to add
|| [[#t16:50:30|16:50]]
|- id="t16:50:45"
! style="background-color: #407a40" | jlaska
| style="color: #407a40" | #info today kamil and me created a simple test, which demonstrates usage of beakerlib-based tests
|| [[#t16:50:45|16:50]]
|- id="t16:50:55"
! style="background-color: #407a40" | jlaska
| style="color: #407a40" | #info we'll be trying to assimilate other tests this week - probably init script testing stuff - and look into some more complex uses
|| [[#t16:50:55|16:50]]
|- id="t16:51:20"
! style="background-color: #8c4a4a" | kparal
| style="color: #8c4a4a" | jskladan described it all
|| [[#t16:51:20|16:51]]
|- id="t16:51:40"
! style="background-color: #407a40" | jlaska
| style="color: #407a40" | alright thanks for the update gang
|| [[#t16:51:40|16:51]]
|- id="t16:51:50"
! style="background-color: #407a40" | jlaska
| style="color: #407a40" | I'll do a quick run through on the 2 remaining AutoQA topics
|| [[#t16:51:50|16:51]]
|- id="t16:51:56"
! style="background-color: #407a40" | jlaska
| style="color: #407a40" | #topic AutoQA - install automation
|| [[#t16:51:56|16:51]]
|- id="t16:52:14"
! style="background-color: #407a40" | jlaska
| style="color: #407a40" | #info Last week, Liam summarized current DVD automation efforts in an email to autoqa-devel
|| [[#t16:52:14|16:52]]
|- id="t16:52:21"
! style="background-color: #407a40" | jlaska
| style="color: #407a40" | #link https://fedorahosted.org/pipermail/autoqa-devel/2010-February/000199.html
|| [[#t16:52:21|16:52]]
|- id="t16:52:51"
! style="background-color: #407a40" | jlaska
| style="color: #407a40" | Automating media (CD/DVD) installs using virt is funky b/c you have to do some strange stuff to provide your own boot arguments
|| [[#t16:52:51|16:52]]
|- id="t16:53:01"
! style="background-color: #407a40" | jlaska
| style="color: #407a40" | so Liam outlined several techniques he's tried
|| [[#t16:53:01|16:53]]
|- id="t16:53:12"
! style="background-color: #407a40" | jlaska
| style="color: #407a40" | including using dogtail to add custom boot args using virt-viewer
|| [[#t16:53:12|16:53]]
|- id="t16:53:26"
! style="background-color: #407a40" | jlaska
| style="color: #407a40" | any feedback folks have on those proposed solutions would be good to have
|| [[#t16:53:26|16:53]]
|- id="t16:53:52"
! style="background-color: #407a40" | jlaska
| style="color: #407a40" | once back from Chinese new year, he'll be working to integrate the best method into the current test
|| [[#t16:53:52|16:53]]
|- id="t16:53:55"
| colspan="2" | * Oxf13 has to bail, need to prepare for next appointment
|| [[#t16:53:55|16:53]]
|- id="t16:54:07"
! style="background-color: #407a40" | jlaska
| style="color: #407a40" | and last up ...
|| [[#t16:54:07|16:54]]
|- id="t16:54:12"
! style="background-color: #407a40" | jlaska
| style="color: #407a40" | #topic AutoQA - packaging
|| [[#t16:54:12|16:54]]
|- id="t16:54:26"
! style="background-color: #407a40" | jlaska
| style="color: #407a40" | more small progress last week on identifying new build dependencies
|| [[#t16:54:26|16:54]]
|- id="t16:54:48"
! style="background-color: #407a40" | jlaska
| style="color: #407a40" | it exploded to 50+ missing deps at one point, but akurtakov helped identify how to address that
|| [[#t16:54:48|16:54]]
|- id="t16:55:08"
! style="background-color: #407a40" | jlaska
| style="color: #407a40" | This seems like the list of deps isn't every finalized :(
|| [[#t16:55:08|16:55]]
|- id="t16:55:21"
! style="background-color: #407a40" | jlaska
| style="color: #407a40" | I'd really like to squash this so I can start making packaging progress
|| [[#t16:55:21|16:55]]
|- id="t16:55:27"
! style="background-color: #407a40" | jlaska
| style="color: #407a40" | any ideas would be appreciated
|| [[#t16:55:27|16:55]]
|- id="t16:55:49"
! style="background-color: #407a40" | jlaska
| style="color: #407a40" | My current plan, is to see if akurtakov (and others) can dedicate some time on IRC To help walk the list of missing deps once and for all
|| [[#t16:55:49|16:55]]
|- id="t16:56:03"
! style="background-color: #4d4d93" | wwoods
| style="color: #4d4d93" | where's the work-in-progress stuff for people who want to help out?
|| [[#t16:56:03|16:56]]
|- id="t16:56:09"
! style="background-color: #407a40" | jlaska
| style="color: #407a40" | #link [[User:Jlaska/gwt]]
|| [[#t16:56:09|16:56]]
|- id="t16:56:39"
! style="background-color: #818144" | adamw
| style="color: #818144" | i would suggest you make progress by starting packaging
|| [[#t16:56:39|16:56]]
|- id="t16:56:57"
! style="background-color: #818144" | adamw
| style="color: #818144" | the only way you can ever be sure about the deps list is when you actually start packaging stuff and find out if it works
|| [[#t16:56:57|16:56]]
|- id="t16:57:02"
! style="background-color: #407a40" | jlaska
| style="color: #407a40" | adamw: I'd like to as well, but I feel like I still don't know how long the packaging road is
|| [[#t16:57:02|16:57]]
|- id="t16:57:18"
! style="background-color: #407a40" | jlaska
| style="color: #407a40" | I'm trying to find the leaf nodes to package ... and every time I look, I find another deps branch
|| [[#t16:57:18|16:57]]
|- id="t16:58:38"
! style="background-color: #407a40" | jlaska
| style="color: #407a40" | so I'll revisit this week, and work towards adamw's suggestion ... just start packaging :)
|| [[#t16:58:38|16:58]]
|- id="t16:58:52"
! style="background-color: #407a40" | jlaska
| style="color: #407a40" | #info current plan, is to see if akurtakov (and others) can dedicate some time on IRC To help walk the list of missing deps once and for all
|| [[#t16:58:52|16:58]]
|- id="t16:58:58"
! style="background-color: #407a40" | jlaska
| style="color: #407a40" | #info I'll revisit this week, and work towards adamw's suggestion ... just start packaging
|| [[#t16:58:58|16:58]]
|- id="t16:59:03"
! style="background-color: #407a40" | jlaska
| style="color: #407a40" | alright ... open discussion time
|| [[#t16:59:03|16:59]]
|- id="t16:59:14"
! style="background-color: #407a40" | jlaska
| style="color: #407a40" | #topic Open discussion - &lt;Your topic here&gt;
|| [[#t16:59:14|16:59]]
|- id="t16:59:26"
! style="background-color: #407a40" | jlaska
| style="color: #407a40" | anything not previously mentioned that we need to discuss today?
|| [[#t16:59:26|16:59]]
|- id="t17:00:32"
! style="background-color: #407a40" | jlaska
| style="color: #407a40" | If no suggestions, I'll close out the meeting in 1 minute
|| [[#t17:00:32|17:00]]
|- id="t17:01:23"
! style="background-color: #818144" | adamw
| style="color: #818144" | nup
|| [[#t17:01:23|17:01]]
|- id="t17:01:36"
! style="background-color: #407a40" | jlaska
| style="color: #407a40" | alrighty ... thanks for the updates everyone
|| [[#t17:01:36|17:01]]
|- id="t17:01:46"
! style="background-color: #407a40" | jlaska
| style="color: #407a40" | as usual, I'll send minutes to the list for review
|| [[#t17:01:46|17:01]]
|- id="t17:01:53"
! style="background-color: #407a40" | jlaska
| style="color: #407a40" | #endmeeting
|| [[#t17:01:53|17:01]]
|}
Generated by irclog2html.py 2.7 by [mailto:marius@pov.lt Marius Gedminas] - find it at [http://mg.pov.lt/irclog2html mg.pov.lt]!

Latest revision as of 09:01, 18 September 2016

Attendees

People present (lines said)

  • jlaska (135)
  • Oxf13 (34)
  • adamw (32)
  • kparal (16)
  • jskladan (11)
  • wwoods (11)
  • zodbot (3)
  • pjones (2)
  • Viking-Ice (1)
  • jeff_hann (1)

Regrets:

Agenda

Previous meeting follow-up

  1. jlaska will follow-up w/ nirik after the meeting to setup zodbot feed watchers
  2. jlaska to work w/ poelstra to give 'release validation' spin to quality milestones

Rawhide Acceptance Testing

Test Summary (see recap)

Next Steps:

  • Fix AutoQA post-tree-compose hook to monitor for RAT droppings (see ticket#115)
  • Commit reviewed patches and rework one proposed change.

Alpha TC test status

Alpha TC#2 is available for testing. Instructions for downloading and providing feedback available at:

IDEA - Live images for test compose milestone

Adamw proposed including live images with future 'test compose' milestones. adamw would like a single set of nightlies to be associated with each TC build and kept available in that TC directory during TC testing

After some debate, no conclusions were reached. Jkeating felt providing nightly live images was not needed.

IDEA - Unique ISO image names for each drop

kparal proposed using unique ISO file names for each official test drop. Kparal was concerned that since each the ISO file names from each test drop are the same, it might not be clear to testers what the latest images to use are. After some discussion, Jkeating noted that the ISO file name produced comes from specific arguments used during the compose process and the current values are tightly integrated with the build process.

Jkeating noted that eventually, this information would be present in a future release engineering SOP (see Composing_Test_Composes).

AutoQA project update

Deps/conflicts prevention

Last week

  • Not much progress, wwoods was out sick for most of last week

This week

  • Build a testsuite to validate depchecks functionality (possibly using rpmfluff)

Results collection

Last week

  • Held design session last week with wwoods, kparal and jskladan (see recap)

This week

  • Continue research on other test frameworks handling of results

Beakerlib integration

Last week

This week

  • we'll be trying to assimilate other tests this week - probably init script testing stuff - and look into some more complex uses

install automation

Last week

This week

  • Chinese new year, so no action expected.

packaging/deployment

Last week

  • Akurtakov's help has been tremendous ... more deps keep popping up and he has helped play wack-a-mole

This week

  • I still don't have a final picture for what needs packaging. I'd like to schedule some sit-down time with akurtakov (others welcome) to finalize the packaging wish-list.
  • Adamw suggested to start packaging a leaf-node dependency just to get the foot in the door

Open discussion - <Your topic here>

Upcoming QA events

Action items

  • No action items

IRC transcript

jlaska #startmeeting Fedora QA Meeting 16:00
zodbot Meeting started Mon Feb 15 16:00:23 2010 UTC. The chair is jlaska. Information about MeetBot at http://wiki.debian.org/MeetBot. 16:00
zodbot Useful Commands: #action #agreed #halp #info #idea #link #topic. 16:00
jlaska #meetingname fedora-qa 16:00
zodbot The meeting name has been set to 'fedora-qa' 16:00
jlaska #topic Gathering 16:00
* kparal raises up his hand 16:00
adamw morning 16:00
jskladan hello 16:00
jlaska greetings folks 16:01
adamw Software Engineer Barbie also says hi 16:01
adamw http://www.engadget.com/2010/02/14/barbies-slides-into-the-cubical-becomes-a-computer-software-en/ 16:01
jlaska I believe maxamillion has a conflict today 16:01
jlaska finally, some mainstream recognition! :) 16:02
adamw looks like me on a good day! 16:02
jlaska adamw: does it come with more accessories (external monitors, bluetooth keyboard(s) etc...) 16:02
adamw this being barbie, all signs point to 'yes' 16:03
jlaska alright ... let's get started. hopefully wwoods, Viking-Ice and tk009 can join in as we go 16:04
jlaska #topic Previous Meeting Review 16:04
jlaska I've only captured 2 items from last week ... 16:04
jlaska #info jlaska will follow-up w/ nirik after the meeting to setup zodbot feed watchers 16:04
jlaska thanks nirik, we can check this off 16:05
jlaska we have zodbot notification for any additions to the F13Alpha, F13Beta and F13Blocker bugs 16:05
jlaska we might want to consider fedora-qa TRAC ticket additions as well 16:05
jlaska #info completed ... IRC zodbot notification for any additions to the F13Alpha, F13Beta and F13Blocker bugs (thanks nirik) 16:05
jlaska next up ... 16:05
jlaska #info jlaska to work w/ poelstra to give 'release validation' spin to quality milestones 16:06
jlaska This is completed as well ... I suggested a minor wording change (nothing crazy) 16:06
jlaska the test milestones are no longer specific to install 16:06
jlaska (e.g. Test Alpha 'Test Compose' and Test Alpha Candidate) 16:06
* Oxf13 is here, sorry 16:06
jlaska Oxf13: welcome! 16:07
jlaska #info completed, the wording around scheduled test milestones are no longer specific to install 16:07
jlaska that's all I had to track from last week ... anything I missed? 16:07
jlaska alright ... diving into the proposed agenda 16:08
jlaska #topic Rawhide Acceptance Test #3 16:08
jlaska Just a quick update on the last of 3 rawhide acceptance test (RAT) drops 16:08
jlaska you probably saw the announcement ... so I'm just summarizing here 16:09
jlaska #info RATS#3 test recap at http://lists.fedoraproject.org/pipermail/test/2010-February/088407.html 16:09
jlaska This milestone helped flesh out a few patches against rats_install 16:09
jlaska thanks wwoods for review feedback, I'll follow-up on those shortly 16:10
jlaska I need to update the RATS watcher script to watch the new URL (see ticket#115) ... I don't have immediate plans to look into that 16:10
jlaska so anyone with interest and time is welcome to pitch in 16:10
jlaska as always, Oxf13 thanks for coordinating the drops with dlehman 16:11
jlaska that's all I had on that ... let's dive into the Alpha ... 16:11
jlaska #topic Alpha TC test status 16:11
jlaska just a quick summary ... then onto some ideas raised by kparal and adamw 16:11
jlaska #info F-13-Alpha-TC2 is available for testing 16:12
jlaska #link QA:Fedora_13_Alpha_TC_Install_Test_Results 16:12
jlaska #link QA:Fedora_13_Alpha_TC_Desktop_Test_Results 16:12
adamw yay desktop testing 16:12
adamw wait, now I actually have to do some 16:13
jlaska woot! 16:13
adamw whose stupid idea was this? 16:13
jlaska adamw: deatils deatils 16:13
jlaska details too :) 16:13
jlaska so first note I have here was from adamw ... 16:13
jlaska #topic IDEA - publish live images along with 'test composes' 16:14
jlaska adamw: you raised this last week, I put this on the agenda so we wouldn't forget 16:14
* Viking-Ice sneaks in.. 16:15
jlaska Oxf13 I believe live images are provided for the release candidate drops (alpha, beta and final) ... with the new focus around desktop validation, are we able to provide them for 'test compose' as well? 16:15
jlaska Viking-Ice: welcome! 16:15
Oxf13 jlaska: well, we already make live images nightly 16:16
jlaska we've historically relied on the nightly images ... but depending on the state of the repo ... we can go days without any live images 16:16
Oxf13 duplicating that work would be, well, duplicated work 16:16
Oxf13 if the repo is busted for making the nightly images, how am I supposed to make them? 16:16
* jeff_hann here, sorry I'm late 16:16
* wwoods appears 16:16
adamw as I said in IRC, there's no need for a separate image generation process 16:16
jlaska wwoods: jeff_hann hey gang 16:16
adamw just take the nightlies from the appropriate day and stick them in the TC directory 16:16
adamw just want to have a single 'approved' live image that everyone's working from 16:17
adamw again, if it's too much work, it's not vital. 16:17
Oxf13 ... 16:17
jlaska yeah, doesn't matter to me which images we use ... just that we have images to test with 16:17
Oxf13 pointing to the live isos at the same time you point to the TC doesn't work? 16:17
adamw Oxf13: no, because anyone who reads it the next day can't use the same image 16:17
adamw but they can still get the right TC images 16:17
Oxf13 I suppose I could just make hardlinks 16:17
adamw Oxf13: the nightlies don't stick around, they get wiped and regenerated every day 16:18
jlaska would kparal's suggestion of always keeping around the previous successful live image build solve this? 16:18
Oxf13 hardlinks would solve this 16:18
adamw no, because you still have the problem if the next build is successful 16:18
adamw it's not that i'm worried a later build won't be 'successful' and no one will be able to test 16:18
adamw just worried that people would be testing with different stuff, leading to possibly confusing results... 16:19
adamw (tester A tests with 2010-02-15 and feature B is broken but feature C works, tester D tests with 2010-02-16 and gets the opposite result, world goes 'huh'?) 16:19
jlaska seems like a reasonable request 16:20
kparal nicely said :) 16:20
adamw Oxf13: yeah, a hardlink should do it I guess. 16:20
jlaska so the issue is making it clearer what people should be testing with ... instead of providing a URL to a directory that may or may not contain images? 16:20
Oxf13 well 16:20
adamw not just that. as I said, at present, it's not just an information issue 16:21
Oxf13 there is the problem of testing the static image instead of the next nightly 16:21
Oxf13 because the next nightly is what's going to be in the release 16:21
Oxf13 so testing what's older isn't all that useful, if the newer is broken 16:21
adamw Oxf13: but that applies equally to the non-live bits 16:21
Oxf13 adamw: except we don't generate the non-live bits every day 16:21
adamw the test compose isn't what's going to be in the release either 16:21
Oxf13 so we don't have the opportunity to test the newer bits 16:21
adamw still, it's difficult to do consistent testing and be sure about the results if different testers are testing different bits. 16:22
Oxf13 adamw: but we're still in "things change daily" 16:22
Oxf13 mode 16:22
Oxf13 we haven't stopped yet 16:22
Oxf13 these TC images aren't us stopping 16:22
Oxf13 they're just a snapshot of something we haven't yet produced this cycle to see what might be broken 16:23
Oxf13 in those specific things we don't always produce 16:23
jlaska so adamw, want to summarize what QA is requesting? 16:23
adamw i think we've wasted enough time already and should just move on 16:23
jlaska yup ... summarize, next steps and we'll move on 16:23
* jlaska suggests excessive use of #info 16:23
adamw if it takes this much debate to get it done it's probably not worth doing 16:23
adamw #info adamw would like a single set of nightlies to be associated with each TC build and kept available in that TC directory during TC testing 16:24
adamw #info oxf13 doesn't believe it's necessary 16:24
adamw next topic. 16:24
jlaska alrighty ... next up, I noted a topic from kparal. But kparal and Oxf13 may have discussed this already 16:25
Oxf13 more like counterproductive to testing the bits that will be in the release. 16:25
kparal I had almost the same question, this time about Alpha TC naming 16:25
jlaska Oxf13: it's something QA is asking for 16:25
jlaska I don't think it's counterproductive 16:25
jlaska we'll follow this up in a ticket after the meeting 16:25
jlaska #topic IDEA - Unique ISO image names for each drop 16:25
jlaska kparal: what's the latest 16:26
kparal well currently all TC iso's are named the same as the final Alpha iso 16:26
kparal Oxf13 replied: by not naming the isos etc the same for TC and the alpha release, we risk missing some bug in the behavior of Anaconda and the release name/number 16:26
jlaska you may have already discussed, but I wasn't clear on how the ISO file names are related to testing itself, was that cleared up? 16:27
kparal I had similar concerns as adamw, people would be testing something other than we expect. or they might suppose they already have the F13 Alpha final iso (it's called like that, isn't it?), but they won't 16:27
pjones kparal: Is there some reason to believe we're likely to have that kind of bug? 16:27
pjones considering that we change the names for every release and haven't been having issues with it... 16:28
jlaska we have people downloading the old ISO's a lot 16:28
kparal well, I wasn't sure why the names are not simply unique 16:28
jlaska normally, we have them validate the CHECKSUMS 16:28
Oxf13 not only that, but the TC stuff is on a completely different mirror system 16:29
kparal so the Oxf13's explanation is above. I didn't know about anaconda issues, then I suppose it makes more sense 16:29
Oxf13 we can't really protect against stupid people. 16:29
Oxf13 buildinstall does do things with version and product which does change anaconda behaviour 16:29
wwoods is there a TC# in the metadata anywhere? It'd be simplest to say "current test candidate is TC7" and then if .treeinfo says test-candidate = 6.. 16:30
Oxf13 of course, this is one of the dangers of opening pre-release test isos up to more people 16:30
wwoods but I don't really want to add new data if we don't have to. timestamps work, but people always get confused 16:30
Oxf13 you risk more people getting them who won't use them responsibly 16:30
Oxf13 wwoods: no 16:30
jlaska Oxf13: I don' think there is bad intent for the images 16:30
Oxf13 wwoods: it's at the top of the URL, but from that point down, by design, it looks exactly like the Alpha would 16:31
Oxf13 jlaska: I don't mean malintent, I mean ignorance 16:31
jlaska just looking for ways to make sure we are doing what's reasonable to make sure people know they are using the latest test images 16:31
jlaska okay 16:31
kparal I think we can move on 16:31
jlaska kparal: Oxf13: so in summary the filename used for the ISO image files is tightly coupled to the whole build process? 16:31
Oxf13 jlaska: yes 16:31
jlaska ah okay, not something I knew about 16:32
jlaska probably one of the new SOPs has this listed 16:32
jlaska Composing_test_images ? 16:32
Oxf13 the input to the compose process drives the name of the iso, I don't manually make the isos and pick a new name each time 16:32
Oxf13 jlaska: probably Composing_Test_Composes once we make that 16:33
jlaska Oxf13: ah sweet, thanks 16:33
jlaska alrighty, kparal anything else to discuss here, otherwise we'll dive into AutoQA 16:33
Oxf13 test_images doesn't have any isos produced (beyond boot.iso) 16:33
kparal we can go on 16:34
jlaska alrighty 16:34
jlaska #topic AutoQA - depcheck update 16:34
jlaska wwoods: you have the mic ... any updates or milestones to share? 16:34
jlaska wwoods: we can come back to this later if you prefer? 16:36
jlaska alright ... moving on to resultsdb ... 16:37
jlaska #topic AutoQA - resultsdb discussion 16:37
jlaska kparal, wwoods or jskladan, anything to add here? 16:38
kparal well I would just mention that we had a small QA team discussion over phone 16:38
kparal and the results are available in autoqa-devel ML 16:38
* wwoods was afk a sec, deferring to kparal for the moment 16:38
jlaska #link https://fedorahosted.org/pipermail/autoqa-devel/2010-February/000201.html 16:38
jlaska wwoods: okay 16:38
kparal we are currently studying other projects, how they define their results database, etc 16:39
kparal so any input can be sent to autoqa-devel 16:39
kparal that's all I suppose 16:40
jlaska kparal: okay, thanks for the update 16:40
jlaska #topic AutoQA - beakerlib 16:40
wwoods the current notion - if memory serves - is that we want to provide one unified resultsdb that al the autoqa tests can use to report (somewhat simplified) results 16:40
wwoods which will give us one place to view all test results - and ideally a few nice views of that data. 16:41
jlaska #topic AutoQA - resultsdb discussion 16:41
jlaska #info we want to provide one unified resultsdb that all the autoqa tests can use to report (somewhat simplified) results 16:42
jlaska one sec ... meeting tags 16:42
jlaska #info had a small QA team discussion over phone last week (results on autoqa-devel ML) 16:42
wwoods I think we had some example views we wanted to see - test results for a given package, test results for a given installable tree, all test results for package builds / updates for a given day, etc. 16:42
wwoods if you can think of a good use case you'd like - a specific view of the autoqa results data - please let us know 16:42
jlaska nice, thanks wwoods and kparal 16:43
wwoods further discussion will be on autoqa-devel. 16:43
wwoods oh, and as for depcheck: no progress, owing to the fact that I was out of the office and then sick all last week 16:43
jlaska status - plague :( 16:44
jlaska #topic AutoQA - beakerlib 16:44
jskladan ok, time for me to speak, i suppose :) 16:44
jlaska Adding a new topic here for the work jskladan and kparal have been looking into around beakerlib 16:44
jlaska any updates or problems you are experiencing? 16:44
jskladan well, idk if all af you are familiar with beakerlib 16:45
jlaska #link https://fedorahosted.org/beakerlib/ 16:45
jskladan its a set of libraries which RHEL guys use for writing automated tests 16:46
jskladan so we'd like to reuse those in out testing system (autoqa) 16:46
jskladan today kamil and me created a simple test, which demonstrates usage of beakerlib-based tests 16:47
jskladan #link http://jskladan.fedorapeople.org/beakerlib_helloworld.tar 16:47
jskladan it's nothing fancy - in fact, it only makes sure, that you have beakerlib installed, and then runs the test itself 16:47
jlaska nice, using the provided beakerlib vim syntax highlight! :) 16:47
jlaska rlAssertRpm "setup" 16:48
jlaska rlAssertExists "/etc/passwd" 16:48
jlaska rlAssertGrep "root" "/etc/passwd" 16:48
jlaska cool 16:48
jskladan and of course stores the report produced by beakerlib in the directory for autotest-lib result files 16:48
jskladan we'll be trying to assimilate other tests this week - probably init script testing stuff - and look into some more complex uses 16:49
jlaska this is great news, it's moving along faster than I had expected 16:50
jlaska nice work :) 16:50
jskladan so that's about it for now - if kamil does not have anything to add 16:50
jlaska #info today kamil and me created a simple test, which demonstrates usage of beakerlib-based tests 16:50
jlaska #info we'll be trying to assimilate other tests this week - probably init script testing stuff - and look into some more complex uses 16:50
kparal jskladan described it all 16:51
jlaska alright thanks for the update gang 16:51
jlaska I'll do a quick run through on the 2 remaining AutoQA topics 16:51
jlaska #topic AutoQA - install automation 16:51
jlaska #info Last week, Liam summarized current DVD automation efforts in an email to autoqa-devel 16:52
jlaska #link https://fedorahosted.org/pipermail/autoqa-devel/2010-February/000199.html 16:52
jlaska Automating media (CD/DVD) installs using virt is funky b/c you have to do some strange stuff to provide your own boot arguments 16:52
jlaska so Liam outlined several techniques he's tried 16:53
jlaska including using dogtail to add custom boot args using virt-viewer 16:53
jlaska any feedback folks have on those proposed solutions would be good to have 16:53
jlaska once back from Chinese new year, he'll be working to integrate the best method into the current test 16:53
* Oxf13 has to bail, need to prepare for next appointment 16:53
jlaska and last up ... 16:54
jlaska #topic AutoQA - packaging 16:54
jlaska more small progress last week on identifying new build dependencies 16:54
jlaska it exploded to 50+ missing deps at one point, but akurtakov helped identify how to address that 16:54
jlaska This seems like the list of deps isn't every finalized :( 16:55
jlaska I'd really like to squash this so I can start making packaging progress 16:55
jlaska any ideas would be appreciated 16:55
jlaska My current plan, is to see if akurtakov (and others) can dedicate some time on IRC To help walk the list of missing deps once and for all 16:55
wwoods where's the work-in-progress stuff for people who want to help out? 16:56
jlaska #link User:Jlaska/gwt 16:56
adamw i would suggest you make progress by starting packaging 16:56
adamw the only way you can ever be sure about the deps list is when you actually start packaging stuff and find out if it works 16:56
jlaska adamw: I'd like to as well, but I feel like I still don't know how long the packaging road is 16:57
jlaska I'm trying to find the leaf nodes to package ... and every time I look, I find another deps branch 16:57
jlaska so I'll revisit this week, and work towards adamw's suggestion ... just start packaging :) 16:58
jlaska #info current plan, is to see if akurtakov (and others) can dedicate some time on IRC To help walk the list of missing deps once and for all 16:58
jlaska #info I'll revisit this week, and work towards adamw's suggestion ... just start packaging 16:58
jlaska alright ... open discussion time 16:59
jlaska #topic Open discussion - <Your topic here> 16:59
jlaska anything not previously mentioned that we need to discuss today? 16:59
jlaska If no suggestions, I'll close out the meeting in 1 minute 17:00
adamw nup 17:01
jlaska alrighty ... thanks for the updates everyone 17:01
jlaska as usual, I'll send minutes to the list for review 17:01
jlaska #endmeeting 17:01

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/20100215&oldid=472366"