From Fedora Project Wiki

< QA‎ | Meetings

The printable version is no longer supported and may have rendering errors. Please update your browser bookmarks and please use the default browser print function instead.

Attendees

People present (lines said):

  1. jlaska (124)
  2. adamw (45)
  3. j_dulaney (34)
  4. maxamillion (29)
  5. nirik (18)
  6. fenris02 (16)
  7. kparal (14)
  8. fcami (7)
  9. ajax (7)
  10. zodbot (6)
  11. jskladan (4)
  12. zaniyah (4)
  13. jeff_hann (4)
  14. wwoods (3)
  15. jsmith (3)
  16. vaschenb (1)

Unable to attend:

  1. Liam
  2. Rhe
  3. Newgle1

Agenda

Previous meeting follow-up

  1. jlaska to inquire how frequently boot.fp.org gets updated F-14 install images
  2. 621864 - jlaska to check-in with skvidal to see whether potential_conflict.py script updates are required for proper %ghost handling
  3. 622058 - jlaska to ping mgracik for guidance on pending firstboot changes

F14 Alpha test milestones

Owner - rhe, adamwill
Summary
F-14 Alpha RC#4 compose CD and DVD images are available for test (see https://fedorahosted.org/rel-eng/ticket/3856)
Alpha test results so far are positive (http://fedoraproject.org/wiki/Category:Fedora_14_Alpha_RC_Test_Results)
1 blocker bug remains (see below)
Next steps...
Continue posting test results (installer or desktop)
Review blocker bugs
RHBZ #596985 (MODIFIED) hang at start of X11 on fresh install from DVD -- discussion took place as to whether this issue was a blocker bug. Initial impression was that this issue is a valid alpha release blocker. However, discussion continued after the meeting. Stay tuned...

Open discussion - <Your topic here>

Developing action plans for Updates_Lessons

Owner - nirik
Summary
I setup Updates_Lessons as part of implementing the boards updates vision thing. We talked today about looking at and learning from updates issues. Would it be reasonable to file a ticket with qa track anytime there is a new update issue and then discuss it in qa how to learn from or prevent it? or would you want fesco to discuss that kind of thing.
Next steps...
nirik will raise topics in FESCO and reach out to stake-holders as needed (rel-eng, qa, devel, infrastructure etc...)
jlaska to fiddle with the wiki page to provide a way to clearly identify the recommendation and tracking the implementation

Nightly live composes

Owner - kparal
Summary
Viking-Ice raised the topic that nightly composes are probably not built from updates-testing repo
nirik confirmed that the nightly live images are based on dist-f14
Next steps...
No next steps required at this time

Upcoming QA events

Action items

  1. adamw and jlaska to propose artwork final release criteria
  2. adamw to update http://fedoraproject.org/wiki/QA:Testcase_desktop_updates to better describe the test experience on live images
  3. jlaska to update QA:Testcase_Anaconda_User_Interface_Basic_Video_Driver so that it better captures the post-install xdriver=vesa expectations
  4. maxamillion update rel-eng TRAC#3860 to request RC#5

IRC Transcript

jlaska #startmeeting Fedora QA Meeting 15:00
zodbot Meeting started Mon Aug 16 15:00:11 2010 UTC. The chair is jlaska. Information about MeetBot at http://wiki.debian.org/MeetBot. 15:00
zodbot Useful Commands: #action #agreed #halp #info #idea #link #topic. 15:00
jlaska #meetingname fedora-qa 15:00
zodbot The meeting name has been set to 'fedora-qa' 15:00
jlaska #topic Previous meeting follow-up 15:00
jlaska #topic Roll Call ... 15:00
jlaska heh ... let's start here first :) 15:00
* kparal rolls 15:01
jlaska hey kparal 15:01
adamw yo 15:01
jlaska adamw: mornin' 15:02
* jskladan waves 15:02
* zaniyah waves 15:02
* vaschenb hooah 15:02
jlaska vaschenb: heh 15:02
* j_dulaney is done doing battle with a Klingon 15:02
jlaska greetings jskladan zaniyah j_dulaney 15:02
* jlaska waits another minute 15:02
j_dulaney My DnD 3.5 character was killed by a six foot tall gnome the other night 15:03
zaniyah lol 15:03
* fenris02 watches out for the grue 15:04
jlaska let's get started ... 15:04
jlaska #topic Previous meeting follow-up 15:04
jlaska a few minor items on the list ... 15:04
jlaska #info jlaska to inquire how frequently boot.fp.org gets updated F-14 install images 15:04
jlaska for my own clarification ... turns out the links point to the F-14 Branched image locations 15:05
jlaska so when you install F-14 from boot.fedoraproject.org, you'll get whatever is on the mirrors 15:05
jlaska news for me, probably common knowledge for everyone else :) 15:05
zaniyah I didn't know 15:05
j_dulaney LOL 15:05
j_dulaney Neither did I 15:05
jlaska yay, I'm not alone! :D 15:05
jlaska #info 621864 - jlaska to check-in with skvidal to see whether potential_conflict.py script updates are required for proper %ghost handling 15:05
j_dulaney Easier to remember to go to boot.fp.org 15:06
jlaska thanks to fcami and skvidal ... the potential_conflicts.py changes have been applied to autoqa.git master 15:06
jlaska next up ... 15:06
jlaska #info 622058 - jlaska to ping mgracik for guidance on pending firstboot changes 15:06
jlaska I think mgracik agrees ... he was pinged, and pulled into the depths of firstboot 15:07
adamw he has The Mark, now? 15:07
* j_dulaney trembles at firstboot 15:07
jlaska special thanks to adamw for moving things along after mgracik went to bed at somewhere in the *early* hours of the morning 15:07
jlaska adamw: yes! :P 15:07
jlaska adamw: I've got the release criteria note for us ... unless there have been any updates, I'm just moving that to next meeting (and hopfeully post f-14-alpha) 15:08
adamw okay 15:09
fenris02 should be as the last alpha-blocker was resolved a few hours ago (testing needed) 15:09
jlaska #info adamw and jlaska to propose artwork final release criteria 15:09
jlaska for the logs, no updates here ... I'll leave this on the list and we'll prioritize post-alpha 15:09
jlaska anything else I missed from last week? 15:09
* jlaska will move on in 20sec 15:09
jlaska alrighty ... 15:10
jlaska #topic F-14-Alpha test status 15:10
j_dulaney I have found a big bug 15:10
jlaska I've got this down for adamw and rhe to guide us through current status 15:10
jlaska adamw: want to start this off with where things are ... along with what's next? 15:11
adamw okay 15:11
jlaska excessive use of #info #help #action encouraged 15:11
adamw so, we have rc4 out, and testing on it looks fine, AFAIK. 15:11
jlaska j_dulaney: hold that thought ... I suspect we'll come to specific issues in a moment 15:11
j_dulaney jlaska: roger 15:12
adamw the big question is the remaining blocker bug: https://bugzilla.redhat.com/show_bug.cgi?id=596985 15:12
jlaska #info RC4 available with good test results so far -- http://fedoraproject.org/wiki/Category:Fedora_14_Alpha_RC_Test_Results 15:12
adamw we have a probable fix for the bug, now. the question becomes, do we consider it a blocker and roll an rc5 with the fix? 15:12
jsmith adamw: If dgilmore is willing to do another RC and you're willing to do testing on it, I think that's probably wise 15:13
fenris02 adamw, only if we cannot get another person to confirm that it does indeed fix the problem 15:13
jsmith adamw: You know better than I do though -- what are your thoughts? 15:13
fenris02 adamw, afaik, it works and should permit us to move on to beta-blockers, pending any other alpha-blocker 15:14
adamw the fix is to xorg-x11-server, which is obviously kind of an important package. 15:14
fenris02 or what jsmith said. 15:14
jlaska has all alpha testing against RC#4 been completed and accounted for? 15:14
adamw as to whether it works, all testers but one report success (no idea why it's failing for one tester, he may have a different bug). 15:14
adamw jlaska: the install matrix is virtually full. desktop matrix is patchy, but we're only short two tests for the alpha criteria. 15:15
jlaska looks like a few Alpha install tests left to complete on the install matrix 15:15
adamw jskladan reports fail doing updates on the desktop iso, which is odd, i'll have to investigate that 15:15
jlaska I can pick a few of those off this afternoon, I suspect they're things folks have done already 15:16
adamw i only really see 'install to scsi' and 'install to pata' 15:16
jskladan adamw: i guess it's because i tried in the virtual machine from livecd 15:16
adamw jskladan: if you think it's something like that, it may be wise to go with 'warn' rather than 'fail'... 15:16
kparal from my experience you need like 1.5GB RAM to do updates from livecd in VM 15:16
jskladan adamw: and i might have runned out of memory (one would think that 1G is enough) 15:16
adamw you shouldn't do a full system update from within a live session anyway, it's just not what we're trying to test 15:17
* adamw will check the test case to make sure it's clear on that 15:17
* jlaska was going to suggest that 15:17
fenris02 you should see the update-notifier though 15:17
jlaska rhe lists 2 bugs with the test case ... QA:Testcase_Anaconda_User_Interface_Basic_Video_Driver 15:17
jlaska .bug 623956 15:17
zodbot jlaska: Bug 623956 Graphical anaconda failed to display in kvm with xdriver=vesa - https://bugzilla.redhat.com/show_bug.cgi?id=623956 15:17
jlaska .bug 623961 15:17
zodbot jlaska: Bug 623961 The installed system is not configured with boot command: xdriver=vesa after installing with basic video driver - https://bugzilla.redhat.com/show_bug.cgi?id=623961 15:17
adamw fenris02: no you shouldn't. that's one of the tests =) 15:17
jskladan adamw: well, i might have misunderstood the test case, but seemed like "Both should correctly install all available updates when you confirm that you wish to do so" is not fulfilled 15:18
fcami pong. hello guys. 15:18
adamw ah, the test case isn't clear, since i adjusted it to check if the update notification shows in live mode, sorry. i'll fix that. 15:18
jlaska fcami: welcome! 15:18
fcami ty jlaska . sorry, I could not be here earlier. 15:18
jlaska #action adamw to update http://fedoraproject.org/wiki/QA:Testcase_desktop_updates to better describe the test experience on live images 15:18
j_dulaney fcamI: lo 15:19
adamw so, anyway, that's the state of play: outstanding issue is to decide whether we fix 596985 and spin rc5 15:19
jlaska fcami: no apology needed, thanks for coming 15:19
jlaska adamw: any thoughts on the 2 issues rhe lists above under one of the alpha tests? 15:19
j_dulaney Has anyone had any issues with fdisk from DVD install? 15:19
fenris02 jlaska, basic-video should always work, even in alpha -- no? 15:20
j_dulaney fenris02: yes 15:20
fenris02 j_dulaney, i used the gui one, it appeared to work. i did not switch vc's to try the cli one though - is that what you mean? 15:20
adamw 623956 is known (well, *I* know about it and mentioned it to ajax) 15:20
adamw i don't think it's very important, as there's no particular reason you'd ever want to boot a kvm with vesa except for testing 15:20
* wwoods appears late 15:20
jlaska wwoods: welcome 15:21
j_dulaney fenris02 I used the gui and got a python error 15:21
* wwoods mumbles something about an incident... involving ants.. alll over the kitchen 15:21
jlaska wwoods: sounds like we had similar weekends 15:21
j_dulaney spray 'em 15:21
fenris02 wwoods, eek. hope you found the anteater 15:21
ajax blah, vesa. 15:21
adamw 623961 is intentional: xdriver=vesa doesn't work as a boot parameter in an installed system, it only works for anaconda or live boot. to make sure the installed system uses vesa, anaconda should write a /etc/X11/xorg.conf file, rather than adding a boot parameter. 15:21
ajax adamw: actually i'd argue we should make the x server notice xdriver= directly. 15:21
jlaska adamw: ah, so a test case may be neded for 623961 15:22
ajax i'm all about having anaconda do less 15:22
jlaska +1 15:22
j_dulaney fenris02: It may be my high number of partitions. See my testlist mail 15:22
fenris02 adamw, imho, it should be a snippet in /xorg.conf.d/ instead 15:22
adamw ajax: well, if you want to go that way, cool - but for now, it's not how stuff works, so it's normal that it's not written to post-boot grub config. 15:22
wwoods using xserver=XXX everywhere would actually be pretty useful, although redundant configuration methods tend to make people a little goofy 15:22
fenris02 j_dulaney, wilco 15:22
adamw fenris02: yes, it should, but anaconda just hasn't changed that yet. 15:23
jlaska #action jlaska to update QA:Testcase_Anaconda_User_Interface_Basic_Video_Driver so that it better captures the post-install xdriver=vesa expectations 15:23
adamw let's try and stick on track here, we're taking up a lot of meeting time. 15:23
* maxamillion is here .... late but here 15:23
maxamillion $dayjob meeting let out early 15:23
maxamillion :) 15:23
* fcami feels less alone 15:23
jlaska adamw: lead on my good man 15:23
j_dulaney guten tag, her maxamillion 15:23
fenris02 maxamillion, lucky man :) 15:23
j_dulaney herr^^ 15:24
maxamillion fenris02: agreed! It almost never happens around here ... people love to have long meetings for some reason 15:24
* j_dulaney can't spell in English, either 15:24
maxamillion ok ... so f14 alpha status, I miss anything on that topic so far? 15:24
zaniyah me neither j_dulaney 15:24
adamw maxamillion: we just finished discussing it :) 15:25
adamw maxamillion: cliff notes version: we have to decide if we're going to fix 596985 and spin an rc5 15:25
jlaska what's the expected user impact of 596985? 15:25
fenris02 anyone with edid borked or some vm's may be unable to install properly 15:26
maxamillion adamw: ah, thanks :) 15:26
* maxamillion looks up 596985 15:26
j_dulaney .bug 596985 15:26
zodbot j_dulaney: Bug 596985 hang at start of X11 on fresh install from DVD - https://bugzilla.redhat.com/show_bug.cgi?id=596985 15:26
maxamillion ah 15:26
maxamillion that one 15:26
adamw jlaska: that's the tricky thing; we're still not entirely sure 15:27
jlaska adamw: how satisfied with results from the 'call for testing' are you? 15:27
adamw jlaska: airlied thought it should be essentially random as it depends on particular memory contents, but that doesn't match up with the testing experience 15:27
fenris02 that's not related to the other ati problem? 15:27
adamw jlaska: reasonably happy so far 15:27
jlaska okay ... I'd suggest firing up the RC#5 machine 15:28
* fcami notes that his weekend was too full to do what he wanted wrt xorg/ati 15:28
jlaska we have a sound RC#4 to fall back on if something happens 15:28
adamw that flies in the face of the theory, but seems sound in practice. =) 15:28
jlaska alternative solutions? 15:28
adamw nothing, really we don't have many options - we ship rc4 or we build and test rc5 and ship that. 15:29
maxamillion adamw: +1 15:30
jlaska has anyone seen the patch for 596985? 15:30
fcami is it kernel or xorg-x11-drv-ati? ajax? 15:30
maxamillion I suppose the main question I'd have is, what exactly would be gained over RC4 by spinning a RC5 if the bug isn't fixed? 15:31
maxamillion "the bug" == 596985 15:31
adamw jlaska: the actual patch? no, i didn't look at the code 15:31
adamw fcami: neither, it's to -server 15:31
ajax i've seen the patch. 15:31
adamw maxamillion: nothing. the fix for 596985 would be the only change. 15:32
maxamillion adamw: oh, so that bug is fixed? 15:32
jlaska ajax: got a link? 15:32
ajax it's a fine patch although it does more work than necessary and isn't the version that'll be upstream i suspect 15:32
jlaska ajax: okay 15:32
adamw ajax: do you have any thoughts on the impact of the bug? why it seems to affect certain systems (and entirely radeon systems) reliably and not affect other systems reliably? is the use of the radeon driver *causing* the problematic memory contents somehow? 15:33
ajax no, it's just a use-after-free 15:33
ajax http://lists.x.org/archives/xorg-devel/2010-August/012026.html and ensuing thread 15:33
adamw ajax: right, but we're still unclear on how to know how many people it'll hit :/ well, if we can't tell for sure, we can't tell for sure 15:35
adamw i guess we'll just go ahead and spin an rc5 and see if we can get testing done in time 15:36
adamw so, let's see - j_dulaney, what was the big bug you found? 15:36
j_dulaney Maybe its because I have so many partitions 15:38
jlaska adamw: +1 on respin for 596985 15:38
j_dulaney But, Fdisk crapped out between telling it how to set everything up and actually formatting/writing partition 15:38
maxamillion +1 to respin for 596985 15:39
jlaska j_dulaney: is there a bz for this issue yet? 15:39
adamw j_dulaney: did you file a bug? do you recall exactly what partition layout you were attempting to use? 15:39
j_dulaney I haven't yet filed a bug because I can't find the log file 15:39
maxamillion ATI cards are everywhere, I think asking people to test an Alpha image that won't launch X might cause an onslaught of duplicate bugs 15:39
jlaska j_dulaney: does anaconda generate an exception report for you? 15:39
j_dulaney Partition layout is in my email I sent to test-list this morning 15:39
j_dulaney It did 15:40
j_dulaney That's what I'm trying to find 15:40
jlaska j_dulaney: the installer allows you to file a bug report directly into bugzilla ... was that option available to you? 15:40
jlaska alright ... let's track this off-list then 15:42
j_dulaney jlaska: The option is there 15:42
jlaska off-meeting I mean 15:42
j_dulaney Roger 15:42
j_dulaney fedora-qa? 15:43
jlaska j_dulaney: try to file the exception into bugzilla using the installer exception reporting dialogs if you can ... I'll follo-wup to your thread on test@ 15:43
adamw right, as long as no-one else is seeing the failure it shouldn't be a problem for alpha 15:43
j_dulaney roger 15:43
jlaska who wants to update the rel-eng TRAC tickets for Alpha RC? 15:43
jlaska adamw, can you grab that? 15:44
maxamillion jlaska: I can I suppose, anything special needing to go in it other than our the plan to spin a RC5 for 596985 ? 15:44
jlaska maxamillion: ah thanks ... yeah, you'll see previous comments from myself and adamw in that ticket ... 15:44
adamw jlaska: sure 15:44
maxamillion jlaska: ok, I'll just model it after those 15:44
maxamillion wait ... who's taking it? 15:44
maxamillion :) 15:44
jlaska it just needs to be open, and a comment indicating we'll need a new RC with a fix for that bug 15:44
jlaska maxamillion: you got it 15:45
maxamillion alright 15:45
jlaska #action maxamillion update rel-eng TRAC#3860 to request RC#5 15:45
jlaska maxamillion: thanks! 15:45
jlaska adamw: anything else on F-14-Alpha you wanted to discuss? 15:45
adamw not that i can think of 15:46
jlaska alrighty, thanks adamw 15:46
jlaska last topic on the agenda ... 15:46
jlaska #topic Developing action plans for Updates_Lessons 15:46
jlaska nirik raised this topic last week regarding Updates_Lessons 15:47
* nirik looks up. 15:47
jlaska nirik: are you available to discuss more on this topic 15:47
nirik sure... 15:47
jlaska you're comments from IRC last week ... 15:47
jlaska "I setup Updates_Lessons as part of implementing the boards updates vision thing. We talked today about looking at and learning from updates issues. Would it be reasonable to file a ticket with qa track anytime there is a new update issue and then discuss it in qa how to learn from or prevent it? or would you want fesco to discuss that kind of thing. " 15:47
nirik right. I think it may make sense for QA to discuss things, and only if there needs to be maintainer actions or the like take it to fesco. 15:48
nirik basically I was thinking of a track ticket when an issue comes up. It can be discussed then and we can try and figure out what we can learn to make it never happen again. 15:49
jlaska I suspect not all of hte issues will be owned by QA ... but QA may have input on 15:49
nirik yeah, more of a 'first stop hit qa', then they can go on to other places. 15:49
j_dulaney makes sense 15:49
jlaska some of this is policy related ... so we may push back to the board for guidance there 15:50
jlaska for example ... "fall of 2009 - PackageKit permissions too lax" 15:50
maxamillion (sorry to back track) when should I propose as the RC5 compose date? 15:50
nirik sure, but I note coming out of that was a security qa policy 15:51
jlaska maxamillion: asap 15:51
maxamillion jlaska: sounds good, thanks .. just wanted to double check 15:51
jlaska nirik: right, which was a good thing ... but not something I'd typically expect *from* QA 15:51
nirik agreed. ;) Above and beyond the call I say. ;) 15:51
jlaska just don't want to setup expectations where QA is expected to drive resolution on all these issues 15:51
nirik sure. So, should we look at tracking issues in fesco and then ask for qa input on them there instead? 15:52
* nirik doesn't much care, but does want to try and track and fix them. 15:52
jlaska That'd be my suggestion ... and we can task out specific QA stuff in fedora-qa 15:52
jlaska the signing is a good example where multiple groups will be needed 15:52
jlaska we discussed updating the policy and creating a test case to cover this in QA ... but there may also be a rel-eng tie-in there too 15:53
jlaska nirik: this is good stuff ... thanks for raising this 15:53
jlaska nirik: might if I fiddle with the wiki page a little? I'd like to clearly spell out recommendations and results for each item 15:53
nirik ok. 15:53
nirik jlaska: please do. 15:53
jlaska nirik: okay thanks 15:54
nirik and feel free to add other issues you have seen/noted. 15:54
jlaska will do 15:54
jlaska alright ... open floor 15:54
jlaska #topic Open discussion - <Your topic here> 15:54
jlaska anything else that needs to be discussed in meeting? 15:54
* jlaska will close out the meeting and let folks get back to bid'ness in 1 minute 15:55
maxamillion jlaska: https://fedorahosted.org/rel-eng/ticket/3860 <--- updated 15:56
kparal ah, one topic from me I guess 15:56
jlaska maxamillion: rockin, thanks! 15:56
kparal nightly composes topic 15:56
jlaska kparal: take it away 15:56
jlaska #topic Open discussion - nightly composes 15:56
kparal on Friday Viking-Ice complained that nightly composes are probably not built from updates-testing repo 15:57
maxamillion jlaska: anytime :) ... hope my verbage is alright, always worry about updates to tickets that my thought process isn't transferred to text worth a crap 15:57
kparal so I think maybe that's something we can mention here 15:57
kparal and maybe nirik can tell us more about it? 15:57
kparal I am also curious whether nightly composes use updates-testing or not 15:57
nirik yeah, they are not. 15:57
kparal and - do we want updates-testing to be used at all or don't we? 15:58
nirik the idea was that we should be testing the thing that we would ship. 15:58
maxamillion that's new-ish because of the no frozen rawhide bit right? 15:58
maxamillion or the need for them to use updates-testing is newish 15:58
maxamillion nirik: ah 15:58
fcami it doesn't really match the expected use case 15:58
nirik there are advantages to going with updates-testing: quicker to get fixes in, more testing of test bits, etc. 15:58
fenris02 why would updates be tied up in -testing anyhow? 15:58
maxamillion fcami: what's "it" in that statement? 15:58
fcami maxamillion: using updates-testing in nightly composes, sorry 15:58
jlaska #info Viking-Ice raised the topic that nightly composes are probably not built from updates-testing repo 15:59
kparal well, for example some RCs contain packages that are not even in updates-testing. some hotfixes and stuff 15:59
jlaska #info nirik confirmed that the nightly live images are based on dist-f14 (aka what we ship) 15:59
kparal and but nightly composes from a later day contain older packages. which is a little weird 15:59
nirik and disadvantages: we arent' testing the thing we would be shipping, when do we switch?, what happens if those things work, but final fails? 15:59
maxamillion fcami: rgr 15:59
jlaska kparal: that is wierd, that's in part because we don't have nightly live or pxeboot images generated from updates-testing 15:59
jlaska kparal: so things that are install-path critical, are pulled into composes before they've been tested in updates-testing 16:00
kparal yes 16:00
jlaska probably some kinks or process improvement to iron out there ... maybe something dgilmore (as a new composer) might have thoughts on too 16:00
kparal so, what do you think, which approach would we prefer more? nightly composes with updates-testing included, or without? 16:01
nirik I'd be happy to change it if there was a consensus to do so from qa and/or spins-sig. 16:01
jlaska I don't know if I'm comfortable with the change just yet ... would need to process more 16:02
nirik personally I feel we should test what we would ship... testing bits that may never be in stable is not a good methodology. 16:02
fenris02 nirik, blindly enablign -testing seems like a bad idea 16:02
jlaska perhaps having installable images (pxeboot + live) for *both* dist-f14 and dist-f14-updates-testing ... but that might be too much ofa big hammer solution 16:02
jlaska we can take this recommendation out of the meeting, I don't think we have all the right people to make a decision here 16:03
jeff_hann Sorry, guys, just arrived from work 16:03
* jlaska would like input from jkeating or dgilmore too 16:03
jlaska jeff_hann: hi there 16:03
jeff_hann howdy y'all 16:03
kparal alright. the important is that I now know the answer what the current approach is :) 16:03
jlaska kparal: definitely 16:03
jlaska okay ... any other topics to discuss 16:03
jlaska otherwise, I'll close out the meeting in 30 seconds 16:03
* jsmith doesn't have anything else 16:04
j_dulaney Keep it fresh, y'all, use a ziplock 16:04
adamw sorry i've been quiet, fighting stupid battles in -devel. 16:04
adamw why the concept of 'minimal changes during rc stage' is so hard to understand i really don't fucking know. 16:04
j_dulaney LOL 16:05
jeff_hann :) 16:05
jlaska adamw: shall I #topic that? 16:05
jlaska :) 16:05
j_dulaney Scientific, man, scientif 16:05
j_dulaney ic^ 16:05
jeff_hann I wanna see this :) 16:05
adamw throw it in your pastebook, whatever. 16:05
j_dulaney see, I can't spell in Englsih, either. 16:05
jlaska alright folks ... let's close this out 16:05
jlaska stay tuned to the list for updates on RC#5 16:05
jlaska thanks to all who have contributed testing so far, but way of wiki, bugzilla or mailing list 16:06
* jlaska will send minutes to the list 16:06
jlaska #endmeeting 16:06

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/20100816&oldid=472374"