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