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