QA/Meetings/20100816

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

• Proposed meeting agenda
• MeetBot summary

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

• 2010-07-29 - Test Alpha 'Test Compose'
• 2010-07-30 - Alpha Blocker Meeting (f14alpha) #3
• 2010-08-05 - Test Alpha Candidate
• 2010-08-06 - Alpha Blocker Meeting (f14alpha) #4
• 2010-08-11 - Fedora 14 Alpha Go/No-Go Meeting (17:00 EST) -- introduced 1 week schedule slip
• 2010-08-18 - Fedora 14 Alpha Go/No-Go Meeting (17:00 EST)
• 2010-08-24 - Alpha Public Availability

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!