From Fedora Project Wiki

< QA‎ | Meetings

Attendees

  • adamw (147)
  • cmurf (92)
  • danofsatx (36)
  • roshi (24)
  • tflink (9)
  • satellit_e (6)
  • zodbot (3)
  • nirik (2)
  • satellit (2)
  • brunowolff (1)
  • akshayvyas (1)

Agenda

  • Previous meeting follow-up
  • FedUp post-mortem
  • Storage validation
  • Open floor

Previous meeting follow-up

  • adamw to push the sanity check proposal out, group seems to approve - this was done
  • adamw to check F19 and F18 commonbugs for issues that should be copied to F20 - this was done, and F19 commonbugs cleaned up a bit

FedUp post-mortem

  • There was a SNAFU with fedup on release day: fedup 0.8 was still in updates-testing for F18 and F19 on the day of release, and it turned out upgrades to F20 with fedup 0.7 and the release upgrade.img do not work
  • Upgrades with 0.8 work fine, this was communicated via Common_F20_bugs#fedup-07-fail and various other means
  • adamw changed the fedup test cases to recommend testing latest stable fedup (instead of updates-testing) against the current TC/RC tree (not development/ tree)
  • It was noted by multiple parties that short RC lifetime is an invitation to issues like the thinp and fedup bugs

Storage validation

  • Storage validation planning continues on list, there seems to be broad agreement to try and cover guided partitioning extensively and custom with a small(ish) 'must work' matrix and a larger 'bonus credit' matrix
  • cmurf was working on a mail to anaconda list proposing a restriction on the breadth of custom partitioning coverage

Open floor

Action items

  • adamw to send fedup/thinp post-mortem email

IRC Log

adamw #startmeeting Fedora QA meeting 16:00
zodbot Meeting started Mon Dec 23 16:00:01 2013 UTC. The chair is adamw. Information about MeetBot at http://wiki.debian.org/MeetBot. 16:00
zodbot Useful Commands: #action #agreed #halp #info #idea #link #topic. 16:00
adamw #meetingname fedora-qa 16:00
zodbot The meeting name has been set to 'fedora-qa' 16:00
adamw #topic Roll call 16:00
adamw ahoyhoy folks 16:00
* satellit listening 16:00
* cmurf is alive 16:00
* danofsatx present (pun intended) 16:01
* brunowolff is here 16:01
danofsatx I will be dissecting an external HD, but I'll be paying attention 16:02
* tflink is here 16:04
* adamw on laptop, technical difficulties on the big boc 16:04
adamw box, too 16:04
* akshayvyas is here 16:04
adamw #topic Previous meeting follow-up 16:05
* satellit anaconda blew awau a failed install to a fat and ntfs ext Hd lost my intrnal HD on main laptop. still reinstalling it 16:05
adamw #info "adamw to push the sanity check proposal out, group seems to approve" - did that, https://lists.fedoraproject.org/pipermail/test/2013-December/119558.html 16:06
adamw #info "adamw to check F19 and F18 commonbugs for issues that should be copied to F20" - did that too, found a few, cleaned up the f19 page a bit while I was in there 16:06
adamw #topic FedUp post-mortem 16:07
adamw so in case anyone didn't know, let me #info the story 16:07
adamw #info there was a SNAFU with fedup on release day: fedup 0.8 was still in updates-testing for F18 and F19 on the day of release, and it turned out upgrades to F20 with fedup 0.7 and the release upgrade.img do not work 16:08
adamw #info upgrades with 0.8 work fine, this was communicated via the commonbugs and various other means: https://fedoraproject.org/wiki/Common_F20_bugs#fedup-07-fail 16:09
adamw I just wanted to throw this item on the agenda so we can see if there's anything to learn here 16:09
adamw anyone have any thoughts on the whole thing? 16:10
cmurf so basically 0.8 came late and took us by surprise 16:10
adamw well, what surprised me was 0.7 not working 16:11
danofsatx It should be one of our test cases in Beta 16:11
adamw i thought 0.8 would be an optional update, we had lots of passes in the matrices and wwoods wasn't yelling about how 0.8 needed to go out or anything 16:12
danofsatx and fedup should be frozen if it works 16:12
cmurf we didn't exactly have a way to test 0.7 client with an 0.8 fedup-dracut produced image though 16:12
adamw the upgrade.img is in the RC tree 16:12
adamw hmm 16:12
danofsatx and, it should be a blocker if it doesn't work 16:13
cmurf the upgrade.img in RC1's tree was built with which version of fedup-dracut? 16:13
adamw cmurf: afaik that's the one we released. the RC1.1 tree was just sent out. 16:13
adamw dgilmore: right? 16:13
adamw danofsatx: it already is tested and blocked on at Beta, but we don't freeze fedup (or anything) at that point. 16:14
danofsatx well then, something in the process is broken. We shouldn't be hit with this issue on release day - we should have known about this with TC4 or 5 16:15
nirik the thing that happens on release day is the mirrormanager link moves from pointing to beta to final. 16:15
adamw so prior to F20 going out, the fedup test case (and the wiki instructions) said to use the latest fedup from updates-testing, and to pass a --instrepo parameter pointing to the development/20 tree on the mirrors 16:16
cmurf well similar to how dracut itself cause LVM thinp to explode with RC1, it seems fedup-dracut version changed with RC1 and caused the tested client side fedup to explode 16:16
* roshi walks in late 16:17
adamw that appears to be the case, yeah, but it wasn't an 'unauthorized' change, we wanted fedup-dracut 0.8 for blocker/FE bugs 16:17
adamw morning roshi 16:17
roshi Wasn't tracking missed messages and didn't think it started yet... :-/ 16:18
cmurf ok then fedup-dracut 0.8 arrived too late to have any practical chance of testing with 0.7 fedup? 16:18
adamw #info adamw changed the fedup test cases to recommend testing latest stable fedup (instead of updates-testing) against the current TC/RC tree (not development/ tree) 16:18
adamw cmurf: no, I'm fairly sure the upgrade.img in each TC/RC tree is the upgrade.img we 'would ship' with that TC/RC. but our test cases did not used to suggest using that tree 16:18
adamw i think perhaps when we wrote the instructions, releng was not generating upgrade.img's along with TC/RC compose, or fedup was just moving too fast and we always wanted to test the latest (this stuff was all written for F18 IIRC) 16:19
cmurf my recollection is that fedup upgrade testing was pretty smooth but also pretty early 16:19
tflink the problem was that until F20, you couldn't use the TC/RC trees with fedup 16:19
adamw my guess is that by bad luck, everyone who tested a 0.8 upgrade.img tested it with fedup 0.8, and everyone who tested with fedup 0.7 tested with an older upgrade.img somehow or other. but if anyone has figured it out any other way... 16:20
* tflink is trying to remember why and what changed 16:20
* adamw has tested that you actually *can* run fedup against RC1.1 tree, fwiw. 16:20
cmurf so i think when fedup-dracut 0.8 landed there just wasn't anyone testing the actual combination of fedup 0.7 and fedup-dracut 0.8 produced updates.img that was going to occur on release day 16:20
adamw cmurf: yeah, that's all I can figure. 16:20
adamw so I think the more true-to-life test case instructions should help, and be more appropriate now we don't expect fedup to change every day 16:21
tflink adamw: yeah, something changed for F20 about how the tree is composed so that you can run fedup against the TC/RC tree but IIRC, it doesn't work against the development/f20 tree 16:21
adamw did when I tested, I think 16:22
cmurf so i guess this might be Nervous Nelly, but I'm getting to the point where any changes to dracut makes me think "oh fuck, red flag, retest anything that involves booting" 16:22
adamw an upgrade.img gets built in the development/ tree daily doesn't it? 16:22
cmurf and by dracut i also mean fedup-dracut 16:22
nirik adamw: yes, unless it fails for some reason... the image creation part. 16:23
adamw cmurf: dracut and fedup-dracut are not maintained by the same people 16:23
cmurf yeah i know, small problem 16:23
cmurf but in any case, it has dracut in the name 16:23
adamw fedup-dracut is conceptually a bit of fedup, maintained by wwoods 16:23
adamw heh 16:23
adamw so, i wouldn't fixate on this being a 'dumb late change' or something like thinp was, the situations were fairly different 16:23
adamw i'd say this one is rather more 'on us' 16:23
adamw (me) 16:24
cmurf on the plus side, 0.8 fedup works quite OK with fedup-dracut 0.8 images 16:24
cmurf so i think it really could have been a lot worse, as in, 0.8 lands in updates testing and likewise has major problems 16:24
adamw cmurf: haven't you heard? failing with separate /var is SIMPLY UNACCEPTABLE and we're ALL TERRIBLE INCOMPETENTS 16:24
adamw oh yeah, sorry to tell you, tflink, but apparently there is something deeply wrong with our test harnes 16:24
cmurf yes i have read that but you know, manufacturered anger and drama are part of the assignment 16:25
tflink adamw: ? 16:25
adamw https://bugzilla.redhat.com/show_bug.cgi?id=1045168#c25 16:25
adamw me? bitter? nooo. 16:25
cmurf (that was sarcasm, btw) 16:25
adamw =) 16:25
adamw cmurf: oh, i am constantly amazed that things aren't much, much worse, but it's part of the job to pretend we're shocked when everything goes wonky and that we can prevent it in future. =) 16:26
tflink adamw: damn, why didn't I think of that ... 16:26
adamw tflink: inorite? all you have to do is say it on bugzilla and it'll magically happen the next day! 16:26
adamw so, I think the test case changes I made ought to shore us up fairly well against this in future 16:26
adamw and, as cmurf says, recognizing the importance of late changes to fedup-dracut (or dracut) and making sure to re-test this kind of thing carefully 16:27
adamw i mostly wanted the agenda item to make sure everyone was aware and see if there were any good ideas i'd missed 16:27
cmurf i think to a great degree some of these things can't be caught by QA 16:28
adamw i think in theory we could catch a lot of the stuff we miss...if we had freeze periods longer than two weeks. 16:28
cmurf ifi there isn't an immutable policy to get certain packages updated by X date before the anticipated release, then there's simply a good chance certain test cases aren't going to find problems related to those packages 16:29
adamw and, you know, didn't build the image we sign off on about 16 hours before it happens. as i remarked on-list, this is not how software usually happens. =) 16:29
danofsatx or if we had 4 times as many testers, with 6 times as many hours in a day available to them for testing 16:29
cmurf right. i was pushing based on TC5 performance, and then a bunch of big changes happened in RC1 that I certainly wasn't expecting were even possible. 16:29
adamw that was partly my bad, for never doing a TC6 - always seemed like RC1 was right around the corner 16:30
cmurf So the reality is, RC1 needs at least as much or more attention than the last TC, even if it doesn't seem like a lot of changes are expected because of how well that last TC tested. 16:30
adamw well, there's lots of 'realities' 16:30
cmurf And somehow a fixed number of hours or days between RCx being available and "go/no-go" 16:31
danofsatx The reality is that _every_little_ change to RC1 from TC5 needs vetted. There *shouldn't* be any.... 16:31
adamw it's a 'reality' that we have more danger of borkage if the shipped candidate only exists briefly before 'go' 16:31
adamw it's also a 'reality' that fedora people really like shipping stuff. especially before christmas. 16:31
adamw so, competing realities! 16:31
adamw which will win?! 16:32
cmurf all of them 16:32
cmurf right now 16:32
tflink I think we know the answer to that question :) 16:32
adamw #info noted by multiple parties that short RC lifetime is an invitation to issues like the thinp and fedup bugs 16:32
adamw perhaps we can't make it a hard 'RCs must always live for X days' but at least make other stakeholder groups aware of the dangers 16:32
cmurf sure 16:32
adamw i hope they're not expecting that our matrices are somehow 100% foolproof 16:32
danofsatx of course they are - we're QA, after all 16:33
adamw hum, idea - we send out a release post-mortem CCed to relevant parties, explaining broadly the stuff we're discussing here? 16:33
tflink I like the idea 16:34
* satellit_e cannot block all changes to builds? for a period after we test until release...? . 16:34
adamw i could do that, or does anyone else want to? 16:34
danofsatx two questions: 1) will anyone read it 2) will anyone do anything with the info (read: care) 16:34
adamw 1) yes, fedora people also love reading long emails with my name at the top! 16:34
adamw 2) i think it might filter into their consciousnesses at least to some degree. can't hurt, i guess. 16:34
adamw #action adamw to send fedup/thinp post-mortem email 16:36
adamw #topic Storage validation 16:36
adamw sooo...it's adam's current pet project time! 16:36
adamw have people been following the email threads? 16:36
cmurf I've read all of the emails on this including the long one 16:36
cmurf i just haven't had time to reply with something meaningfully coherent 16:37
cmurf The main thing is I agree with categorizing/prioritizing the test matrix: #1 critical must work, #2 in between, #3 bonus 16:37
cmurf so that testers have some understanding of emphasis, not all tests are equally important 16:38
adamw cmurf: ooh, well your mails so far have sure helped me so if you have something better coming i'm all ears =) 16:38
adamw cmurf: the thing that's been most interesting to me was going back over the history of previous releases and realizing/remembering that we really didn't used to test custom part hardly at all 16:38
danofsatx we were supposed to reply? 16:38
* danofsatx missed the memo 16:38
cmurf i like the bonus points one showing the insanity of what "needs" testing (or at least the potential for testing) and think it getting big is just fine 16:39
cmurf the more holes are there due to testers simply not having the time (or interest) to test those bonus items I think shows not only what resources are still needed, but shows what feature maybe aren't all that needed 16:39
cmurf and also down down down the road, when features are proposed, QA can say "yeah your feature is probably a #3 on our test matrix so good luck testing it yourself" 16:40
cmurf vs "yeah this is cool, we'd put that in #1 or #2 and hopefully ensure it works as designed" 16:40
adamw danofsatx: god yes please 16:40
adamw cmurf: yeah, i actually saw the same purpose to the huge, optional matrix idea: point people at it when they moan about how terrible we are for not testing everything 16:41
adamw "feel free!" 16:41
cmurf yes 16:41
cmurf the other day I counted a MINIMUM of an 80 cell test grid for just Guided partitioning 16:42
cmurf it's like, really? 16:42
adamw so, i feel like you and I are kinda getting on the same train and might be able to come up with something we both liked, i just hope everyone else is on board too :) 16:42
adamw right 16:42
cmurf and then custom? oh god 16:42
adamw it's crazy sauce 16:42
cmurf yes 16:42
adamw i keep hoping someone's got a magic matrix that makes it make sense but i'm starting to think it really isn't my drafting skills, just the problem space 16:42
cmurf no it's the realm of tesseracts and other such things 16:43
cmurf the reality we have doesn't match up with the reality we require 16:43
adamw i guess the other thing that comes into consideration here is the wiki-tooling question, because we kind of are stretching the bounds of wikitables at this point 16:43
cmurf yes 16:43
danofsatx what about for custom, just considering the options where custom partitioning is most likely required 16:43
adamw it's not like it'd make the actual test space any smaller, but it would be useful especially for storage if we had something better for tracking validation testing 16:43
adamw danofsatx: yeah, as far as custom goes that was broadly my most recent thought 16:44
danofsatx like coming from a previous install and wishing to keep /home, and God forbid, /var 16:44
adamw danofsatx: in my last email the 'priority #2' matrix was the bits of custom partitioning we decided covered really important functions 16:44
adamw like the 'poor man's upgrade' etc 16:44
danofsatx really? did thunderbird eat that one? 16:44
* danofsatx goes spelunking 16:44
adamw either that or you fell asleep after paragraph #46 16:45
cmurf danofsatx: I think Guided probably ought to have a way to preserve an existing /home on a new install, it's sorta weird we're like "yay easy install Fedora 19" and then for Fedora 20 you either use fedup or custom partitioning to preserve /home. It's a completely different experience. 16:45
adamw danofsatx: look for the mail "More on storage validation strategy (was: Re: Criterion revision proposal...)" 16:46
danofsatx cmurf: yes, I wholeheartedly agree. Guided partitioning not asking if you wish to reuse / keep an existing /home partition is broken IMHO 16:46
adamw well...it's a bit feature creep-y, because that's quite a sophisticated thing to try and 'help' with 16:46
cmurf it will let you reuse / by first clicking delete, so that it gets reformatted 16:46
cmurf adamw: all it needs to do is add that /home to fstab 16:47
adamw that's not really re-using 16:47
adamw it needs to identify it first 16:47
adamw What Could Possibly Go Wrong, right? 16:47
cmurf reusing / seems like a bad idea and dlehman has been absolutely opposed to it in the past, consistently 16:47
adamw you're the one who reads all the storage bugs ;) 16:47
adamw cmurf: deleting an existing / and partitioning in the empty space is hardly 're-using'... 16:47
cmurf use existing /home seems uncontroversial 16:47
cmurf adamw: yeah do not allow reusing then 16:48
adamw it's a common hack, but i'm not sure they'd want to add it to Guided. but you could ask by all means 16:48
cmurf adamw: reuse that partition OK, reuse that volume, NO 16:48
adamw i had the idea of a sort of 'custom-lite' for assigning mount points but not creating new volumes, but that doesn't seem to have gone anywhere 16:48
cmurf And I'm about an inch away thinking about that for Btrfs which is the one exception to the "must reformat" root policy 16:48
cmurf Instead, it's allowed that we (must) create a new subvolume for root, on an existing Btrfs volume 16:49
adamw god, i'm about an inch away from trying to figure out a way to erase btrfs from existence, it would make so many things simpler 16:49
cmurf not true 16:49
cmurf erase everything else and go only with Btrfs and things get simpler 16:49
adamw okay, you also have the option of erasing everything *else* instead 16:50
adamw just pick one way, universe. you get one way. 16:50
cmurf you get LVM, RAID, partitioning all built into one thing that basically can't blow up short of kernel regressions 16:50
adamw okay, so, let me see if I can #info some semblance of order into this 16:50
adamw #info storage validation planning continues on list, there seems to be broad agreement to try and cover guided partitioning extensively and custom with a small(ish) 'must work' matrix and a larger 'bonus credit' matrix 16:51
adamw has anyone had any thoughts about wording criteria? 16:51
adamw that's the other end you can come at the problem from 16:51
adamw if someone can come up with wording for the final release criterion that we'd be happy with, we can then work from the angle of writing matrices that back that 16:51
roshi I can help with criteria wording 16:52
cmurf adamw: think about installing to LVM thinp on RAID6 and making that bootable. is that sane? 16:53
* satellit_e will base server and workstation have different anacondas? with different tests? 16:53
cmurf does anyone do that? 16:53
cmurf what about making bootable raid4? huh? why? 16:53
cmurf there's a lot of stuff in custom that's just, it's kooky 16:53
roshi well, custom just gives you a bunch of options - right? 16:54
roshi there aren't a ton of conditional decision trees for what kinds of configurations you can do 16:54
roshi are there? 16:54
adamw there aren't trees, no 16:54
cmurf yeah well i think they should be yanked and just not there 16:54
cmurf or or or 16:54
roshi there, jus tplant some trees 16:54
adamw cmurf: the problem with that is we're then maintaining a list of what's 'sane' and what isn't... 16:54
cmurf new boot parameter 'crazy' which gets you the current Manual Partitioning functionality 16:55
roshi and we're tied to this whole "has to boot" thing, right? 16:55
cmurf but by default, no effin raid4 option, no raid6 option, not LVM on raid option, no LUKS on LVM on RAID6 option 16:55
danofsatx If we're deciding what's sane, who gets to decide if we are? 16:55
cmurf i mean JESUS, there's a reason why giant ass Microsoft and Apple don't do *anything* like this 16:55
roshi we do, danofsatx 16:55
cmurf they couldn't evne QA this 16:55
cmurf they wouldn't want to 16:56
cmurf roshi right - you offer it, it has to work 16:56
cmurf so i'm like, let's just chop chop chop 16:56
roshi well, to be fair - they have a hard time QA'ing the things they *mean* to release 16:56
danofsatx yeah, I'm a personal fan of all M$'s hidden "features" 16:56
roshi cmurf: I was being facetious about the boot thing, as in "does Fedora *have* to boot? What if it just partially boots?" 16:57
cmurf dracut shell? 16:57
cmurf pass 16:57
adamw roshi: it's on my list to take a look at some of the things in the criteria that got...unexpected interpretations in f20 cycle and see if i can tighten them up 16:57
cmurf technically it booted, which constitutes the kernel and initramfs working 16:57
adamw it was clear from some of the blocker meetings that there are reasonable interpretations which i didn't really consider in the wording 16:57
danofsatx and by booting, does that mean with a working display, or headless? 16:57
cmurf danofsatx: sure 16:58
cmurf in my view there's boot, startup, gdm and shell phases 16:58
adamw cmurf: are you planning to make a proposal to anaconda along these lines? 16:58
danofsatx dont' forget sddm and lightdm 16:58
roshi that makes enough sense to me cmurf 16:59
danofsatx well, sddm is the only other blocker 16:59
cmurf adamw: i was planning on responding to your email to the anaconda list 16:59
roshi adamw: I'll pitch in for the wordings 16:59
cmurf adamw: but when F18 alpha landed and I looked at newui, I said all of these things 16:59
cmurf i was like "WTF, seriously raid4, fucking get rid of it" and all I heard were crickets 16:59
adamw danofsatx: as of f20 we block on gdm and kdm. 17:00
adamw cmurf: you may have a more sympathetic audience now, but i dunno 17:00
cmurf where would Fedora be without a graphical installer? no where. but then also where could we be without an anaconda that doesn't actually try to eat the user for lunch because it doing way way too much. 17:00
danofsatx F21 is sddm. F20 is kdm. 17:01
* satellit_e sddm is on KDE live (rawhide) atm 17:01
danofsatx keep up ;) 17:01
cmurf before I go to anaconda again, i'd like to better understand what QA people think are sane, maybe sane, and not at all sane, layouts 17:01
danofsatx http://fedoraproject.org/wiki/Changes/SDDMinsteadOfKDM 17:02
adamw danofsatx: i said 'as of f20'. 17:02
danofsatx I know - but the time for blocking F20 is done. 17:03
adamw anyhoo 17:03
cmurf I think custom partitioning is what it is and all we can really focus on are a few test cases within that subset, and hopefully all guided options working as intended and that's about it. 17:03
adamw cmurf: i'm not entirely sure it's QA's call, but i think you're the one with the most experience in that line anyhow 17:03
adamw but if you post a mail to the list asking for input i'll contribute 17:03
adamw #info cmurf working on a mail to anaconda list proposing a restriction on the breadth of custom partitioning coverage 17:03
adamw so i think we're still kinda working on this but at least we're getting somewhere... 17:04
adamw we're over time, though, so moving on 17:05
cmurf we have until september apparently 17:05
adamw #topic Open floor 17:05
adamw hah. 17:05
adamw well, we have until alpha tc1 to make major changes to validation 17:05
cmurf yes i'm sorta kidding 17:05
danofsatx which is what anywhere from april to august? 17:05
adamw it's not usually a good idea to mess with the validation process after that (and it angers the viking) 17:05
adamw danofsatx: april to $WHO_KNOWS 17:05
roshi I'm working on the wiki with danofsatx to make the onboarding process a bit smoother 17:06
roshi the working doc is here: https://fedoraproject.org/wiki/User:Roshi/QA/Join 17:06
danofsatx so, like I said last week - expected ETA of F21 sometime in 2016 17:06
cmurf If anything I'd like storage validation stuff to be able to affect Rawhide before branch occurs. :-\ 17:06
roshi once I get it ironed out a bit more I'll send an email to test@ for feedback :) 17:06
adamw roshi: danofsatx: awesome, thank you guys 17:06
cmurf well, there will be an F21 in 2014, we just don't know if it's F20+1 or if it's Fedora.next. 17:07
adamw #info roshi and danofsatx working on a draft for an improved onboarding process at https://fedoraproject.org/wiki/User:Roshi/QA/Join 17:07
roshi and then still with the "test maps" which I think can alleviate some issues with testing the different products for the WGs 17:07
danofsatx and I'm trying to figure out a better method of categorizing/finding the test cases. Right now, it's cryptic at best. 17:07
roshi I also roped danofsatx into test maps and decrypting testcases 17:08
adamw danofsatx: in my mind we're kind of unusual for a QA group in that things are mostly centered around our processes and our test cases are aids to those, rather than the test cases being the centre of everything 17:08
roshi er, what he said 17:08
* satellit_e I like the #1-#3 prioriitys for test cases 17:08
adamw but maybe that doesn't make sense to anyone else... 17:08
adamw i rarely wake up and think 'hey, i'll go find a test case', y'know 17:08
cmurf adamw: what do you think of working with docs team to specifically point out QA recommended installation layouts? 17:09
roshi ...but what else is there adamw ? 17:09
danofsatx it's not that, but when one of you senior guys say "this is checked in test case foo_widget partitioning", and newbies like roshi and I can't find said test case to see exactly how it's laid out 17:09
adamw cmurf: some kind of guidance in the install guide seems like a good idea, yeah, and docs folks are easy to work with 17:10
adamw hah, 'senior' 17:10
danofsatx k, "more experiences in the QA process for Fedora" 17:10
cmurf adamw: like a concise summary of the storage validation test matrix, that steers people to our #1 list of layouts and at least informs them that QA isn't testing 'crazy' 17:10
adamw danofsatx: open the matrix and ctrl-f, jeez! ;) 17:10
adamw cmurf: i think it'd need to be a bit more abstracted from strict QA considerations, but i like the general idea 17:11
adamw danofsatx: does experience count if we drink it all away? 17:11
adamw #info cmurf suggests working with docs folks to highlight 'recommended' custom layouts 17:11
roshi that's an xp boost, double xp weekend adamw 17:11
* danofsatx done killed those brain cells long, long ago (in a galaxy far, far away....) 17:12
adamw okay, any other business? any topic areas I missed that we should be chattin' about right now? 17:14
danofsatx uh, Merry Christmas/Happy <insert Holiday here> ? 17:15
satellit_e +1 17:15
tflink meeting next week? 17:16
roshi when is that even? 17:16
cmurf yeah i expect nothing on my emails for docs and anaconda until after the holiday 17:17
cmurf s 17:17
adamw a very genial winter solstice to all indeed 17:17
danofsatx when is what? next week, is well, next week.... 17:17
adamw (don't matter who you are, everyone celebrates the solstice) 17:17
adamw we could skip next week's meeting possibly 17:17
cmurf adamw: i did not, i celebrated the day after 17:17
roshi I celebrate winter Lagers and Christmas Ales :) 17:17
adamw for the more recent folks - there is a provision in the meeting SOP to skip meetings on weeks when there's nothing much that needs discussing 17:17
cmurf which is "hell yeah, it's no longer getting any darker!" 17:17
adamw hehe 17:17
cmurf yesterday i went snowboarding to celebrate 17:18
adamw so if it looks like being a slow one next week i might send out a mail proposing we skip the meeting, and if anyone really wants to have one (ahahahahaha) they get to object 17:18
cmurf 14" in 48 hours 17:18
adamw cmurf: rrrrrrr 17:18
roshi I'm fine whatever for the meeting next week 17:18
cmurf only hit 5 rocks! 17:18
cmurf (and no core shots) 17:18
adamw cmurf: still mostly artificial on the vancouver mountains :( 17:19
adamw that's why i've been getting more work done than usual :P 17:19
danofsatx snow? 17:19
adamw yeah 17:19
* danofsatx lives in South Texas. 17:19
cmurf that sucks work is overrated, 14" of pow is never overrated 17:19
adamw indeed 17:19
cmurf esp on a board 17:19
adamw alrighty, thanks for coming folks 17:19
* satellit_e bend is too warm - snow is melting : ( 17:19
adamw same time next week or not, depending on interest and how drunk adamw is 17:20
adamw snow sports discussion to continue in #fedora-qa ;) 17:20
adamw #endmeeting 17:20

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

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