QA/Meetings/20131223

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

• roshi and danofsatx working on a draft for an improved onboarding process
• cmurf suggests working with docs folks to highlight 'recommended' custom layouts

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!