QA/Meetings/20120409

Attendees

• adamw (153)
• VICODAN2 (111)
• tflink (36)
• nirik (22)
• brunowolff (13)
• Martix (12)
• jreznik (12)
• Viking-Ice (8)
• Cerlyn (7)
• robatino (5)
• zodbot (3)
• rbergeron (3)
• rdieter (1)
• satellit_ (1)

Agenda

• Previous meeting follow-up
• Fedora 17 Beta status / blocker review
• Test Day report
• Upcoming QA events
• AutoQA update
• Open floor

Fedora 17 Beta status / blocker review

• Current_Release_Blockers
• Need to spin RC4 ASAP: blockers remained in anaconda/preupgrade and selinux
• #809707 was rejected as a beta blocker as we can only think of very few cases which will be hit by it, and there is an obvious 'workaround' (really, the fix): correct the system date

Test Day report

• Turnout for the Power Management Test Day on 04-04 was good, looks like a solid bunch of results. It was open house in Brno, so a lot of input came from that
• Seems to have been solid data in the Installation l10n/i18n Test Day on 04-05 but the results table is a little odd, may need tidying up

Upcoming QA events

• KDE 4.8 Test Day tomorrow (04-10) - KDE team is on top of preparation
• Virtualization Test Day 04-12 - virt team is taking a freeform testing approach, looks like they have the page set up as they want it
• Beta Go/No-Go scheduled (again) for 04-11

AutoQA update

• No news, once more

Open floor

• Some discussion of whether preupgrade bugs should block media spins: adam to propose changes on the list
• Andre noted that mediacheck is now 'hidden' and should be exposed or enabled by default: see #809663

Action items

• adamw to send formal proposal for preupgrade criteria adjustment to the list

IRC Log

adamw	#startmeeting Fedora QA meeting	15:00
zodbot	Meeting started Mon Apr 9 15:00:07 2012 UTC. The chair is adamw. Information about MeetBot at http://wiki.debian.org/MeetBot.	15:00
zodbot	Useful Commands: #action #agreed #halp #info #idea #link #topic.	15:00
adamw	#meetingname fedora-qa	15:00
zodbot	The meeting name has been set to 'fedora-qa'	15:00
adamw	#topic roll call	15:00
adamw	well hey, it appears to be meeting time again.	15:00
tflink	it does indeed	15:00
* tflink thinks the attendance is going to be a bit light today		15:01
adamw	likely	15:01
adamw	who's around? come crawl out of the woodwork	15:01
adamw	if it's just me and you we may as well cancel	15:02
* Cerlyn is here		15:02
* brunowolff is here		15:02
* nirik is lurking around as always		15:03
* satellit_ listening		15:03
adamw	ooh, the woodwork is positively slithering, it appears.	15:03
VICODAN2	HI	15:05
adamw	hi dan.	15:05
VICODAN2	how goes it?	15:05
adamw	so, we don't have anything from last week that i can think of	15:05
VICODAN2	i just woke up	15:05
adamw	anyone else think of anything to follow up on?	15:05
VICODAN2	probably nothing i can offer that hasn't been talked about already	15:06
VICODAN2	i installed RC3 yesterday on a VM	15:06
adamw	okay, let's skip previous meeting follow-up then	15:06
adamw	#topic Fedora 17 Beta status / blocker review	15:07
adamw	so, not looking great here, we have no rc4 and still two open blockers, it seems. unless i missed something this morning.	15:07
VICODAN2	nope sounds about right	15:07
* Viking-Ice sneaks in		15:07
adamw	anyone heard anything from mgrepl or wwoods through any side channels?	15:08
tflink	nope	15:08
brunowolff	I saw a bunch of updates did get pulled in to F17 stable over the weekend.	15:08
nirik	that was the gnome 3.4 update.	15:08
VICODAN2	the login screen still shows the sql server login	15:09
adamw	brunowolff: yeah, we're tidying up the stuff from rc3.	15:10
brunowolff	It looks like today's compose failed. Though it's kind of an odd looking error.	15:10
adamw	VICODAN2: that one's not a beta blocker. think desktop team was bikeshedding it, but it should be gone for final one way or another, i guess.	15:10
VICODAN2	yea i'd like to have a word with them	15:11
VICODAN2	oh	15:11
VICODAN2	package dependencies seems to be fixed	15:11
VICODAN2	no more problems when running yum update after installing a bunch of packages with customize now	15:12
VICODAN2	i did have to install twice yesterday, but im going to blame virtualbox on that	15:12
adamw	so, basically, seems we need to get out the pokey sticks and start poking mgrepl and wwoods. not a whole lot we can do till then.	15:12
VICODAN2	nope	15:12
adamw	rbergeron: have you been performing official pokeage?	15:13
VICODAN2	maybe hes poking them now	15:14
adamw	she	15:15
VICODAN2	she's been idle for 20 mins	15:16
adamw	oh, well.	15:16
adamw	tflink: we don't have any blockers to review, right?	15:16
adamw	oh, hey, we do have one new one.	15:16
adamw	the other two proposed are already discussed, i just didn't secretaryize from friday yet, my bad.	15:17
adamw	#topic Beta blocker review: http://bugzilla.redhat.com/show_bug.cgi?id=809707	15:17
VICODAN2	LOL	15:18
adamw	this sounds worse reading through it than it does from the summary...	15:19
VICODAN2	this is not a blocker	15:19
Viking-Ice	Do we have any "date" criteria	15:19
Viking-Ice	if not then not a blocker just regular bug	15:19
VICODAN2	this is lamer than the y2k bug	15:19
Cerlyn	it's a failure to boot due to the RTC not being correct	15:19
adamw	yeah.	15:19
adamw	that's the problem: if you have system date earlier than 2012-01-29 for any reason (newly bought system, duff system clock, testing something) you get a crash on boot.	15:20
VICODAN2	someone needs a new cr2032	15:20
VICODAN2	yeah but this is complaining about 1-1-2000	15:20
VICODAN2	1-29-2012 is a bigger problem but not as big :P	15:21
Viking-Ice	is it not rather rare that that is the case	15:21
Cerlyn	This comes up on early XO-1.75 prototypes which occasionally reset their clock for no reason	15:21
VICODAN2	really?	15:21
adamw	Cerlyn: yeah, I was wondering about the XO case	15:21
brunowolff	I am thinking this is a blocker. But it looked like there was a simple change that could be done to avoid triggering the bug and I think that would be OK for Beta.	15:22
adamw	but if they're prototypes...then i guess it's kind of annoying for prototype testers, but not a huge issue	15:22
VICODAN2	oh is that the laptop for the african children?	15:22
Viking-Ice	and nobody with the XO team investigating why the clock reset's itselfs?	15:22
Cerlyn	Production units should not be prone to doing this provided they aren't kept in storage improperly to the point the RTC battery drains	15:22
rbergeron	adamw: not this morning yet. /me is on phone in meeting, i will flog shortly	15:22
adamw	rbergeron: set whips to stun	15:23
adamw	so we're kind of left with the generalized 'some kind of weird oops or the RTC battery ran out' case, really	15:23
VICODAN2	yup	15:23
tflink	sounds like a conditional violation of the "needs to boot into graphical env" criterion	15:24
VICODAN2	not a blocker, but a bug none the less, i can think of way more important things to worry about	15:24
Cerlyn	Is there any known signs that clock values other than an RTC reset may cause this?	15:24
adamw	Cerlyn: well, any value before jan 29th causes it.	15:25
adamw	but there's very few reasons to have a system date that wrong that i can think of.	15:25
VICODAN2	good thing it's April 9th	15:25
rbergeron	adamw: willdo	15:25
VICODAN2	doesn't NTP start before Gnome?	15:26
tflink	assuming you have it turned on, yes	15:26
Viking-Ice	in any case I vote -1 on blocker even NTH since this is more an exception than a rule that this happens	15:26
VICODAN2	well, problem solved.	15:26
adamw	VICODAN2: ntp isn't enabled by default	15:26
VICODAN2	i know.	15:26
VICODAN2	you have to have dead battery and ntp turned off for this to happen	15:27
adamw	but yeah, i think i'm with viking-ice, the cases that are going to hit this are just too corner-y and there's an obvious 'workaround' (fix the darn date)	15:27
VICODAN2	i have a better chance of winning the lottery	15:27
adamw	probably +1 final blocker, but -1 beta	15:27
tflink	yeah, this seems like a rather hairy failure mode but I'm not sure it's beta blocker worty	15:28
brunowolff	It won't be obvious that setting the correct date in the bios is the needed fix. So it would be nice to have this documented with commmon bugs.	15:28
Viking-Ice	yeah +1 final	15:28
VICODAN2	+1	15:28
Cerlyn	+1	15:28
adamw	tflink: gnome's failure modes now are just hairy in general. in gnome2 if g-s-d crashed you got a basically working desktop with fonts and sizes and window theme and so on that you didn't specify. in gnome3 you get the fail whale. progress!	15:28
tflink	at least its obvious when something goes wrong	15:29
VICODAN2	can we just move back to gnome 2?	15:29
adamw	propose #agreed 809707 is rejected as a beta blocker as we can only think of very few cases which will be hit by it, and there is an obvious 'workaround' (really, the fix): correct the system date	15:29
VICODAN2	i propose a move back to gnome 2	15:29
adamw	VICODAN2: not here, you don't.	15:29
adamw	:P	15:29
VICODAN2	:(	15:29
tflink	adamw: ack	15:30
VICODAN2	its funny	15:30
VICODAN2	you install f17	15:30
VICODAN2	login	15:30
VICODAN2	and you are presented with an empty desktop	15:30
brunowolff	I'd prefer to see common bugs suggestion for this one.	15:30
VICODAN2	with like	15:30
VICODAN2	"windows" and "activities"	15:31
adamw	brunowolff: stick 'commonbugs' in the keywords list	15:31
adamw	VICODAN2: the desktop battles belong on devel list, or desktop list, or really anywhere that's not here. =)	15:31
Martix	regarding Test Days, could you approve mail for tomorrow test	15:32
Martix	day?	15:32
VICODAN2	it's really terrible, i'll look them up.	15:32
adamw	Martix: will do	15:32
Martix	adamw: thanks	15:32
adamw	any more acks?	15:32
brunowolff	For right now I was suggesting ammending the proposal, but if no one has any objections, I'll just mark the bug.	15:32
adamw	oh okay	15:32
adamw	commonbugs proposing doesn't really have to follow nth/blocker procedure	15:32
Cerlyn	adamw: Do we wish to propose it as a final blocker in the same motion, or is that a later vote?	15:33
VICODAN2	it's a final blocker	15:33
brunowolff	ack	15:33
adamw	you can nominate a bug for commonbugs any time, at your own authority, it's just a 'suggestion' to people who like to update the page	15:33
adamw	Cerlyn: i was going to keep it for later just to keep things simple	15:33
adamw	it sounds like it'll likely get fixed before we hit final blocker review anyhow	15:33
VICODAN2	yep	15:34
adamw	#agreed 809707 is rejected as a beta blocker as we can only think of very few cases which will be hit by it, and there is an obvious 'workaround' (really, the fix): correct the system date	15:34
VICODAN2	also	15:35
VICODAN2	other workaround is use ntp	15:35
adamw	anything else anyone's worried about for beta?	15:35
VICODAN2	well	15:35
VICODAN2	let me tell you about my experience yesterday	15:35
VICODAN2	again this is in a vbox vm	15:35
VICODAN2	i install f17	15:35
VICODAN2	im at the end	15:35
VICODAN2	"congratulations fedora is installed!" "remove the cdrom and reboot!" remove cdrom from drive and press reboot and it hangs	15:36
VICODAN2	do hard reset, reboot and im dropped in to a grub shell	15:36
VICODAN2	booted off DVD again, did an upgrade and it was fine	15:36
tflink	VICODAN2: have you filed a bug?	15:36
adamw	if it's not reproducible and you didn't get logs from the failure, there's not a whole lot anyone can do with that.	15:36
VICODAN2	no. I want to reproduce it again	15:36
VICODAN2	and i was hoping rc4 would drop soon	15:37
tflink	VICODAN2: make sure you grab the logs from the failed install	15:37
VICODAN2	so I could report it against RC4	15:37
VICODAN2	well it technically wasn't a "failed install"	15:37
VICODAN2	when is RC4 dropping?	15:37
tflink	not sure, we're waiting for blocker fixes	15:38
VICODAN2	so a week? 2 at most?	15:38
tflink	the hope is in the next day or two	15:38
VICODAN2	k	15:38
tflink	but we're getting a bit off into the weeds for a meeting, here	15:38
VICODAN2	i'll wait for rc4 and try it again	15:39
VICODAN2	how do i grab logs from anacdona/install?	15:39
tflink	VICODAN2: can you ask in #fedora-qa, this is getting off topic for the meeting	15:39
VICODAN2	yessir	15:39
tflink	thanks	15:39
adamw	okay, so, there we are.	15:39
VICODAN2	anything else?	15:39
VICODAN2	i need to get to work	15:40
adamw	#info rc4 is waiting on blocker fixes, we are trying to ping responsible parties.	15:40
adamw	#topic Test Day report	15:40
adamw	VICODAN2: the agenda's at https://fedoraproject.org/wiki/QA/Meetings/20120409	15:40
adamw	so we had power management test day - https://fedoraproject.org/wiki/Test_Day:2012-04-04_Power_Management - and installer i18n/l10n test days last week - https://fedoraproject.org/wiki/Test_Day:2012-04-05_L10n_I18n_Installation	15:41
adamw	did anyone make it out to those? I suck at attending test days lately.	15:41
VICODAN2	yep	15:41
VICODAN2	i did	15:41
VICODAN2	i did power management day	15:41
adamw	how'd they go?	15:41
VICODAN2	pretty good	15:41
VICODAN2	lots of people ran the reports	15:41
VICODAN2	i was impressed as to how well it was actually working	15:42
VICODAN2	f17 was actually able to read my battery info through a virtualbox vm	15:42
VICODAN2	i18n/l10n, didnt attend, dont know anything about it	15:43
adamw	looks like we got good turnout for the pm day, yup.	15:43
adamw	#info turnout for the power management test day was good, looks like a solid bunch of results - https://fedoraproject.org/wiki/Test_Day:2012-04-04_Power_Management	15:43
Martix	it was Open House in Brno office :-)	15:43
VICODAN2	brb, hoppin in the shower	15:44
Martix	so many people got involved	15:44
adamw	cool	15:44
adamw	#info PM test day was open house in Brno	15:44
adamw	#info seems to have been solid data in the i18n/l10n installation test day too, but the results table is a little odd, may need tidying up	15:45
adamw	#topic upcoming events	15:46
adamw	so it looks like we have KDE 4.10 tomorrow and Virtualization on Thursday	15:46
adamw	er, 4.8, rather	15:46
adamw	#info KDE 4.8 Test Day tomorrow - https://fedoraproject.org/wiki/Test_Day:2012-04-10_KDE_4.8	15:46
VICODAN2	when we say "virtualization" are we mainly concerned with KVM?	15:47
Martix	yep, I am looking for your test reports :-)	15:47
adamw	#info Virtualization Test Day on Thursday - https://fedoraproject.org/wiki/Test_Day:2012-04-12_Virtualization_Test_Day	15:47
adamw	VICODAN2: yep	15:47
VICODAN2	k	15:47
adamw	VICODAN2: it means 'fedora virt stack' - see the page	15:47
VICODAN2	yep	15:47
jreznik	for kde 4.8 rdieter prepared the image, we are finishing test cases, ltinkl reviewed Martix's testcases, looks good	15:47
adamw	so the kde page has test cases but the results table is still generic and no special live images up	15:47
jreznik	also some marketing is done	15:48
jreznik	adamw: yep, I know	15:48
adamw	jreznik: looks like you need to update the image links and results table - cool	15:48
jreznik	will be fixed once we will have all testcases	15:48
adamw	we'll get the test-ann mail approved	15:48
adamw	great	15:48
jreznik	adamw: Martix should update the link to image, at least he promised it :)	15:48
adamw	#info KDE team is on top of preparation for tomorrow	15:48
Martix	jreznik: thanks, but we need finish more test cases	15:48
adamw	#info virt test day is taking a freeform testing approach, looks like they have the page set up as they want it	15:49
Martix	jreznik: its already updated	15:49
jreznik	Martix: ok	15:49
Martix	jreznik: waiting for sha256 verification	15:49
jreznik	I'd like to combine test cases with freeform tests on the rest topics we don't have a test case	15:49
adamw	oh yeah, i just saw the 'tbd' and missed the links, d'oh :)	15:49
adamw	jreznik: you can certainly do that if you get enough people in IRC to get the chat flowing	15:50
Martix	x86_64 image passed media verification, I'll add sha256 sum, but still downloading i686 image	15:50
Martix	or can rdieter provide sha256 sums for his images?	15:51
Viking-Ice	VICODAN2, I would go as far to say the only thing we care about kvm ( because it's the only solution we can actually do anything about )	15:51
rdieter	Martix: good idea, I totally forgot about that.	15:51
jreznik	adamw: I hope to ge traffic but we completely forgot Easter, so a lot of people still on vacations :)	15:52
adamw	ah, well, we'll see :)	15:53
adamw	okay, so they're both looking pretty well prepared for, let us know if there's anything we can do to help jreznik	15:53
adamw	aside from showing up of course :)	15:53
jreznik	adamw: yep, thanks :) Martix is still around, so we have a good fedora qa guy taking care of it :)	15:54
adamw	well, i wouldn't say 'good'....<ducks>	15:54
adamw	oh, and go/no-go is set for wednesday once more.	15:55
adamw	i'm not saying it means anything, just that i've seen World Domination For Beginners in martix's desk drawer	15:55
jreznik	adamw: :) I should probably use a different word :) amazing? awesome? :)	15:55
adamw	and he keeps sending in expense requests for sharks and lasers	15:55
* jreznik knows Martix for several years...		15:56
Martix	adamw: hehe, we must block Fedora Beta release for all costs! </irony> :-D	15:56
adamw	:P	15:57
adamw	okay, so looks like upcoming events are under control	15:57
* jreznik hopes :)		15:57
adamw	#topic AutoQA update	15:57
adamw	i'm guessing there's no news here again?	15:57
tflink	nope, we've been pretty consumed w/ F17 beta testing AFAIK	15:58
adamw	fun. :/	15:59
adamw	#info there is no news. ding.	15:59
adamw	#topic Open floor	15:59
VICODAN2	back	16:00
adamw	so, i did have one thing for open floor, though we're slightly over time	16:00
VICODAN2	go on...	16:00
adamw	i can send a formal proposal to the list, but - it actually occurred to me last week as we were slipping a release for a bug in preupgrade that there's no damn reason to slip releases for bugs in preupgrade.	16:01
adamw	even if they're on the anaconda side.	16:01
VICODAN2	that's my bug :)	16:01
VICODAN2	i give you permission to move it to final blocker	16:01
* rbergeron doesn't look at this line		16:01
adamw	am i missing anything? or should we just treat all preupgrade blockers as 'special' the way we currently treat livecd-iso-to-disk blockers?	16:01
tflink	I assume that the rationale is something along the lines of "as long as some upgrade method works"?	16:02
adamw	no	16:02
adamw	the rationale is that preupgrade doesn't pull anything from anywhere that goes out as media	16:02
brunowolff	That's assuming we know the fix needs to be in preupgrade, not in some f17 package.	16:02
adamw	no	16:02
adamw	think about it :)	16:02
tflink	adamw: the difference in my mind is that most livecd-iso-to-disk bugs can be fixed outside of the release	16:02
adamw	what's the problem with testing preupgrade?	16:02
adamw	we always have to wait for a stable update push to test it	16:03
VICODAN2	why not just get rid of preupgrade all together?	16:03
adamw	it's so annoying...the only way we can test preupgrade blockers is to update the tree on the mirrors...just re-spinning the media doesn't help...	16:03
adamw	*gears whirring*	16:03
adamw	then why are we blocking media composes on preupgrade bugs? :)	16:03
tflink	officially, yes but now that we have a method of testing preupgrade before everything hits stable, it's a little easier	16:03
tflink	because preupgrade requires interaction with anaconda, which can't be fixed by updates	16:04
adamw	tflink: follow the thought process, though. point is, preupgrade process and media composes are completely independent of each other, effectively.	16:04
adamw	yes it can. for preupgrade.	16:04
VICODAN2	look	16:04
adamw	preupgrade never uses the anaconda on the media. it always pulls its anaconda from the tree on the repos.	16:04
VICODAN2	you can upgrade via yum right?	16:04
VICODAN2	you can upgrade via dvd right?	16:04
tflink	I didn't think that preupgrade pulled from updates, though	16:04
adamw	if we ship Beta with anaconda that's 'broken' re preupgrade, and we then push an anaconda update that fixes preupgrade stable, does preupgrade start working?	16:04
tflink	I thought that it always pulls from stable	16:04
adamw	tflink: there is no updates before release	16:05
adamw	there are only two repos for f17 at present: updates-testing and 'stable'	16:05
adamw	when we approve an update, it goes to 'stable'	16:05
VICODAN2	lol "stable"	16:05
tflink	adamw: updates/updates-testing - not stable was what I was getting at	16:05
adamw	tflink: there is no 'updates' for branched releases. the tree is empty.	16:05
VICODAN2	but it pulls from updates-testing by default anyway	16:05
tflink	adamw: preupgrade uses the initrd and vmlinuz from the tree	16:05
adamw	tflink: right. but that gets rebuilt every day from whatever's in 'stable'. as soon as we push a fixed anaconda, we get a new vmlinuz/initrd on the mirrors.	16:06
tflink	we do?	16:06
VICODAN2	lol	16:06
tflink	I thought that was only updated on the mirrors @ releases	16:06
adamw	i believe so. i might be wrong, of course.	16:06
VICODAN2	again, why do we need preupgrade?	16:06
VICODAN2	last question before i leave	16:06
adamw	tflink: no, otherwise we'd never get preupgrade behaviour changes except at alpha, beta and final.	16:07
adamw	VICODAN2: in theory, it's a more reliable mechanism than yum. we don't officially support yum upgrades. preupgrade is the supported 'online' upgrade method.	16:07
VICODAN2	i would say let's deprecate preupgrade and make yum the new standard	16:07
VICODAN2	yum works great	16:07
VICODAN2	i've upgraded from 11->12->13->14->15 via yum	16:07
VICODAN2	the only thing	16:08
VICODAN2	is making yum handle the new boot process stuffs	16:08
VICODAN2	which ims sure it could do	16:08
brunowolff	You need to know special things to to yum upgrades between some releases, preupgrade is supposed to hide that from you.	16:08
VICODAN2	that's my $.02	16:08
tflink	adamw: have we had many changes in preupgrade that required anaconda fixes? the one that I remember from F16 required changes in preupgrade only	16:08
adamw	there would not be any support for that from devel side. they are fairly strongly of the opinion that yum is not a supportable upgrade mechanism. it's sidetracking the question of whether preupgrade issues need to block media composes, anyway.	16:08
VICODAN2	no need to hide it	16:08
tflink	unless I'm just mis-remembering	16:08
adamw	nirik: can you confirm or deny whether i'm right about how branched tree works?	16:09
brunowolff	For you maybe. For lots of people yes.	16:09
VICODAN2	well, we aren't getting much "support" from the devel side on preupgrade now are we?	16:09
* nirik reads up.		16:09
VICODAN2	has anyone done any work on this?	16:09
adamw	while we're doing that - preupgrade goes out and reads https://mirrors.fedoraproject.org/releases.txt to find out where to get its anaconda from.	16:09
VICODAN2	i found the bug like a month or two ago	16:09
adamw	VICODAN2: which bug? there have been like eight preupgrade bugs, in serial. we fix one of them at a time, and keep finding more.	16:10
VICODAN2	f16, preupgrade to 17	16:10
adamw	VICODAN2: the current preupgrade blocker was not filed by you. it was filed by me.	16:10
adamw	https://bugzilla.redhat.com/show_bug.cgi?id=810391	16:10
nirik	adamw: right. there's updates-testing and empty updates, and a 'base' repo. We rebuild the base repo every night with anything thats going to stable.	16:10
VICODAN2	so mine was fixed then eh?	16:10
VICODAN2	all i know is that it's still not working	16:10
VICODAN2	ill check my bug then	16:10
adamw	nirik: so say we build rc4 right now, then we get an anaconda that fixes preupgrade tomorrow	16:10
VICODAN2	build rc5!	16:11
VICODAN2	:P	16:11
adamw	nirik: whenever that anaconda gets pushed 'stable', preupgrade will start working, right? it doesn't matter that it wasn't in the rc4 compose?	16:11
nirik	adamw: I think so, unless preupgrades releases.txt points to the release instead of the f17 devel tree.	16:11
VICODAN2	ok my boss just called me and yelled at me	16:11
VICODAN2	i need to go now, i've caused enough havoc here	16:11
VICODAN2	have fun y'all	16:11
adamw	nirik: it uses https://mirrors.fedoraproject.org/releases.txt	16:11
tflink	nirik: I didn't think that the devel tree was mirrored in many places	16:11
tflink	ie most mirrors use the release	16:12
adamw	nirik: what's that pointing to?	16:12
tflink	but I could easily be wrong	16:12
brunowolff	And if the bug is in preupgrade, that will be fixed in earlier releases. So I am buying that preupgrade should not block composes.	16:12
nirik	adamw: correct. that points to whatever we point it at. ;) Right now it points to the devel tree.	16:12
nirik	tflink: all mirrors who do rawhide should also have f17	16:12
nirik	right now we have:	16:13
nirik	(flood coming)	16:13
nirik	[Fedora 17 (Beefy Miracle)]	16:13
nirik	stable=False	16:13
nirik	preupgrade-ok=True	16:13
nirik	version=17	16:13
nirik	mirrorlist=http://mirrors.fedoraproject.org/mirrorlist?repo=fedora-17&arch=$basearch	16:13
nirik	installmirrorlist=http://mirrors.fedoraproject.org/mirrorlist?path=pub/fedora/linux/development/17/$basearch/os/	16:13
adamw	brunowolff: well, thinking about it, so far i think it shows that preupgrade shouldn't block alpha or beta composes	16:14
adamw	Final may be a different question	16:14
adamw	nirik: for final releases, what does preupgrade use? is it using the original 'frozen' release tree, i.e. whatever anaconda we shipped at release time?	16:14
nirik	yeah, we do point to releases for final.	16:14
adamw	okay	16:14
adamw	(though we could probably improve that if we wanted, i guess.)	16:15
nirik	mirrorlist=http://mirrors.fedoraproject.org/mirrorlist?repo=fedora-16&arch=$basearch	16:15
nirik	installmirrorlist=http://mirrors.fedoraproject.org/mirrorlist?path=pub/fedora/linux/releases/16/Fedora/$basearch/os/	16:15
adamw	so, i think i'm right in that alpha and beta composes can disregard preupgrade	16:15
tflink	yeah, that makes sense to me	16:15
adamw	okay...can anyone else see anything we're not accounting for?	16:15
adamw	if everyone's following the logic so far, i'll send a proposal to the list - guess the easiest thing is just to push the preupgrade criterion to final	16:16
tflink	sounds like a plan	16:16
nirik	I'd be worried if we moved all preupgrade to final tho	16:16
adamw	'all preupgrade'?	16:17
brunowolff	Just because it blocks composes doesn't necessarily mean we wouldn't block a release if needed fix for say anaconda hadn't gone to stable.	16:17
nirik	well, if we ignore preupgrade for alpha and beta it means at final we would have a nasty set of russian dolls of bugs to try and fix before release.	16:17
adamw	nirik: not being blocking doesn't mean it gets 'ignored'	16:17
nirik	right.	16:17
adamw	nirik: we usually try and do the whole matrix at alpha and beta stages	16:17
adamw	but yeah, i take the point	16:18
adamw	i guess we can discuss further on list	16:18
nirik	just wanted to clarify that it wasn't ignoring it... just not blocking composes.	16:18
adamw	thanks for letting me kick that one around :)	16:18
adamw	#action adamw to send formal proposal for preupgrade criteria adjustment to the list	16:18
adamw	anyone have anything else for open floor?	16:18
robatino	long term, the mediacheck needs to be exposed again	16:18
robatino	i filed https://bugzilla.redhat.com/show_bug.cgi?id=809663	16:18
robatino	right now, it's not discoverable for install discs	16:19
adamw	right, i saw that bug	16:19
adamw	#info mediacheck is now 'hidden' as it was previously part of loader, it can be prompted with a cmdline parameter but most people won't know that: https://bugzilla.redhat.com/show_bug.cgi?id=809663	16:20
tflink	wouldn't the required change be in lorax/pungi?	16:20
* tflink can't remember if pungi does anything with the syslinux menu off the top of his head		16:20
robatino	and it might be good to modify the final criteria to require mediacheck (we could do it right now since it's there already)	16:22
robatino	just its existence, i mean, not having it done by default	16:22
adamw	right, i think we have a dormant list thread about that? maybe wake it up	16:24
adamw	okay...anything else?	16:25
tflink	I have some other questions about the preupgrade issue, but they can wait for the email thread	16:26
adamw	okie dokie	16:26
* adamw sets fuse for 2 minutes		16:26
adamw	thanks for coming, all!	16:28
adamw	#endmeeting	16:28

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