21:01:13 <rbergeron> #startmeeting F17 Beta Go No-Go Meeting
21:01:13 <zodbot> Meeting started Wed Apr  4 21:01:13 2012 UTC.  The chair is rbergeron. Information about MeetBot at http://wiki.debian.org/MeetBot.
21:01:13 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
21:01:17 <adamw> yo.
21:01:33 <rbergeron> #meetingname F17 Beta Go No-Go Meeting
21:01:33 <zodbot> The meeting name has been set to 'f17_beta_go_no-go_meeting'
21:01:36 * brunowolff is observing
21:01:46 <rbergeron> #chair adamw brunowolff robatino
21:01:46 <zodbot> Current chairs: adamw brunowolff rbergeron robatino
21:01:46 * adamw is multitasking
21:01:51 <rbergeron> #chair tflink
21:01:51 <zodbot> Current chairs: adamw brunowolff rbergeron robatino tflink
21:02:08 <rbergeron> #topic Go/No-Go Meeting.
21:02:12 <rbergeron> #info We meet again.
21:02:51 <adamw> *zombie*
21:03:03 <rbergeron> #info Today we shall review the state of RC3, check outstanding blocker bugs, and evaluate progress on testing, to answer the question that everyone wants to know the answer to: Should I stay or should I go?
21:03:13 <rbergeron> #info For F17 Beta to be clear
21:03:42 <rbergeron> adamw: yeah. zombie.
21:04:04 <rbergeron> adamw: shall we start with blockers?
21:04:08 <rbergeron> #topic Blocker list
21:04:24 <rbergeron> #link https://fedoraproject.org/wiki/Current_Release_Blockers
21:04:45 <rbergeron> #info We have no proposed blockers unless someone made one in the past few minutes.
21:04:53 <adamw> there ought to be one showing up presently.
21:05:17 <rbergeron> I think it takes a few minutes to refresh.
21:05:28 * nirik is around.
21:05:29 <rbergeron> #info And someone did, thus, it's not appearing.
21:05:38 <rbergeron> adamw: want to walk us through it?
21:05:40 <robatino> would be nice to be able to manually trigger an update
21:05:56 <robatino> handy during meetings
21:06:01 <adamw> robatino: you'd need ssh access to jlaska's system or something. =)
21:06:03 <brunowolff> I thought there was also someone who commented that a previously fixed problem wasn't fixed on the mailing list.
21:06:17 <adamw> brunowolff: didn't see that. linky?
21:06:36 <rbergeron> 804813?
21:06:47 <rbergeron> it was showing up as n accepted blocker not long ago.
21:06:49 <brunowolff> I'm looking ...
21:07:20 <adamw> #topic http://bugzilla.redhat.com/show_bug.cgi?id=810005
21:07:25 <adamw> this is the one tflink just found, anyhow.
21:07:33 <rbergeron> it's in assigned, was previous fixed for RC1.
21:07:39 * rbergeron pays attention to adamw
21:08:02 <adamw> okay, looks like this should be okay, but anyway
21:08:23 <adamw> impact here is that any case where you're pulling stage2 from the network is broken
21:08:30 <adamw> obvious example is pxe
21:08:42 <adamw> actually, that's about the only plausible practical use case, but eh
21:09:25 <adamw> so you're just booting a kernel / initrd, and you should be able to specify 'repo=http://somewhere.out.there/foo'
21:09:45 <rbergeron> #chair bcl
21:09:45 <zodbot> Current chairs: adamw bcl brunowolff rbergeron robatino tflink
21:09:50 <adamw> and it should go ahead and do kernel/dracut then pull anaconda itself (which is now a file called squashfs.img, fact fans...) from wherever you specified
21:09:54 <adamw> problem, it doesn't.
21:10:08 <adamw> good news, we just figured a workaround. silly fugly workaround, but easily documentable, and works.
21:10:09 <brunowolff> I am having trouble finding it. It may have actually been  a comment to a bug I was cc'd on and I remembered it wrong.
21:10:23 <brunowolff> I'll keep looking.
21:10:28 <adamw> since this is something of a corner case, i'm fine with a workaround. i really can't think of an actual use case here besides PXE install.
21:10:48 <rbergeron> brunowolff: okay, it just sounded like it jived with 804813 reappearing
21:10:53 <adamw> the workaround is to specify root=live:http://blahblah repo=http://blahblah . this is totally contrary to how we want it to work, but it works.
21:10:57 <rbergeron> as usual i am coming up with the wrong answer :)
21:11:10 <adamw> bcl: did i screw anything up there?
21:11:26 <rbergeron> how corner casey is it?
21:11:50 <adamw> eh, handwave
21:12:00 <adamw> PXE is pretty commonly used in enterprise deployment situations i think
21:12:12 <adamw> but anyone using PXE should be smart cookie enough to read the commonbugs at least
21:12:16 <adamw> it's not going to hit Joe Phoronix Reader
21:12:19 <rbergeron> yeah that's my thought
21:12:22 <brunowolff> That was it. Bug 804813 reappearing.
21:12:28 <bcl> err, sec.
21:12:32 * nirik is ok with document and fix before final based on that.
21:12:51 * rbergeron fistpumps for being right
21:12:54 <adamw> wait for bcl to tell me how i'm getting it wrong.
21:12:54 <rbergeron> (for once)
21:13:13 <adamw> let's do one at a time.
21:13:15 <rbergeron> i am in agreement with nirik.
21:13:19 <bcl> I actually haven't been following that close. wwoods would know.
21:13:21 <rbergeron> adamw: yeah, I was just gloating :)
21:13:39 <rbergeron> (and preventing him from needlessly searching forever)
21:14:16 <adamw> bcl: i think he's onto his second drink already, right? =)
21:14:20 <adamw> i think i'm about right, though.
21:14:42 <tflink> adamw: what about vm isntalls taht only pull in kernel and initrd?
21:14:50 <adamw> virt-install ?
21:14:52 <bcl> yeah, looks reasonable given what I know about how we parse things now.
21:14:55 <tflink> IIRC, most xen installs do that
21:15:07 <adamw> xen's final.
21:15:23 <tflink> you can do the same with kvm/qemu but I think its less common
21:15:26 <j_dulaney> Sorry I'm late
21:15:47 <adamw> tflink: yeah, usual way with qemu/kvm is to use an image to boot from. i've only done that 30 times today. =)
21:15:53 <j_dulaney> I take it by the bug discussion that we're slipping again?
21:15:54 <adamw> hey dulaney.
21:15:57 <adamw> not necessarily.
21:16:26 <rbergeron> #chair j_dulaney
21:16:26 <zodbot> Current chairs: adamw bcl brunowolff j_dulaney rbergeron robatino tflink
21:18:18 <adamw> so...it's a quick determination, but i think we're probably okay with document for this one, right?
21:18:20 <adamw> -1 blocker +1 nth
21:19:06 <j_dulaney> - blocker +1 nth as well
21:19:11 * rbergeron agrees -1 blocker, +1 nth, +3000ml caffeine injection
21:19:15 <j_dulaney> Since there's a workaround
21:19:32 <j_dulaney> .moarbacon rbergeron
21:19:32 <zodbot> rbergeron, here, have some more bacon
21:19:43 * nirik nods. -1 blocker, +1 nth
21:19:44 <rbergeron> thanks zodbot, i needed a bigger ass.
21:19:49 <adamw> oh, for the bureaucracy
21:19:57 <adamw> PXE is in a weird status that we never get around to fixing
21:20:04 <adamw> the test case is marked 'Alpha' priority and has been forever
21:20:07 <adamw> but there's no matching criterion
21:20:07 <bcl> yeah -1 blocker, +1nth
21:20:13 <adamw> i keep noting this and never get around to fixing it.
21:20:21 <tflink> with the criteria as is -1 blocker, +1 nth
21:20:30 <adamw> but even if we assume that 'pxe broken' is alpha blocker, i'm -1 / +1.
21:20:47 <rbergeron> adamw: can we seriously commit to going through these go-no-go meetings on may 11th and looking at all of the "oh gee we never fixed that" - my end, your end, whatever, and see about capturing that stuff in retrospectives and actually fixing it?
21:20:51 <rbergeron> :)
21:20:57 <rbergeron> (can discuss later, too fried now)
21:21:06 <adamw> rbergeron: i usually do that, actually, we did a lot of criteria revision for 17
21:21:08 <rbergeron> i just hate coming to these meetings and being like, "oh yeah, we said that"
21:21:13 <adamw> pxe just always seems to fall through the net for some reason
21:21:14 <rbergeron> "last time"
21:21:16 <rbergeron> okay
21:21:17 * nirik wants to move go/nogo to thursdays. ;)
21:21:26 <adamw> nirik: hey, that's a good idea!
21:21:42 <brunowolff> Yes please. Less incentive to do crazy stuff if we do that.
21:21:45 <rbergeron> nirik: I hereby dub you "Dude to Make Us Remember That"
21:22:00 <nirik> ok. can try.
21:22:02 <j_dulaney> LOL
21:22:08 <brunowolff> If only we had a program manager to keep track of that stuff.
21:22:09 <rbergeron> which involves flogging me or my ... inheritor
21:22:21 <j_dulaney> #info nirik to make sure we remember to do Go/No Go on Thursdays
21:22:40 <j_dulaney> You gave me chair!
21:22:59 <adamw> propose #agreed 810005 is rejected as a blocker: even if we assume that PXE blocks alpha (its status is unclear), there is a good enough workaround that can be documented
21:23:10 <j_dulaney> ack
21:23:16 <rbergeron> brunowolff: I hear htat tomorrow I wil finally find out when that will get posted so that I am not trying to do many things and doing them poorly :)
21:23:50 <brunowolff> ack
21:23:58 <rbergeron> ack
21:24:30 <adamw> #agreed 810005 is rejected as a blocker: even if we assume that PXE blocks alpha (its status is unclear), there is a good enough workaround that can be documented
21:24:46 <adamw> #topic https://bugzilla.redhat.com/show_bug.cgi?id=804813
21:24:49 <adamw> since it's been re-opened
21:24:57 <adamw> so, this is odd, because i've tested that this morning, and it worked fine for me.
21:25:30 <adamw> bcl: any take on this? likely pilot error, or what?
21:27:03 <bcl> no idea really.
21:27:14 <rbergeron> can we get a tiebreaker? :)
21:27:19 <bcl> If you've tested it I'd believe that :)
21:27:48 <j_dulaney> I didn't hit this either
21:28:14 <adamw> bcl: maybe related to the last bug actually, somehow?
21:28:22 <adamw> his original report says he tested with PXE
21:28:26 <adamw> so i can only assume he still is...
21:29:10 <adamw> actually
21:29:12 <adamw> i bet that's what it is
21:29:20 <adamw> same thing, right? the parameter splitting
21:29:21 * nirik nods. sounds likely.
21:29:31 <bcl> that would make sense.
21:29:34 <adamw> he's doing a PXE install so it's being parsed early to try and find squashfs
21:29:50 <adamw> so it winds up just getting 'nfsiso' not 'nfsiso:10.2.1.1:/blahblah', explosions.
21:30:03 <adamw> I'M ON FIRE
21:30:43 <bcl> boom
21:30:53 <rbergeron> so.......... ?
21:31:07 <j_dulaney> .fire adamw
21:31:07 <zodbot> adamw fires adamw
21:31:54 * rbergeron trusts y'all and looks for proposal
21:32:19 <adamw> so, lessee
21:33:24 <adamw> propose #agreed we believe the reporter who re-opened #804813 is actually suffering from #810005, as he says in the initial report that he is booting via PXE. Two other reporters confirm that in a DVD/netinst boot, repo=nfsiso works as intended. Therefore the bug should be closed
21:33:46 <brunowolff> ack
21:33:49 <nirik> ack
21:34:15 <j_dulaney> ack
21:34:21 <rbergeron> ack
21:34:35 <adamw> #agreed we believe the reporter who re-opened #804813 is actually suffering from #810005, as he says in the initial report that he is booting via PXE. Two other reporters confirm that in a DVD/netinst boot, repo=nfsiso works as intended. Therefore the bug should be closed
21:37:13 <adamw> um
21:37:23 <adamw> #topic other blockers
21:37:28 <adamw> i don't think we need to do these one at a time, right?
21:37:54 <adamw> i can confirm 802475 is addressed, as boxes is out of the default package set - my VMs came up with working network
21:38:07 <adamw> actually, let's do that one
21:38:09 <adamw> #topic https://bugzilla.redhat.com/show_bug.cgi?id=802475
21:38:45 <adamw> propose: #agreed this bug can be demoted to non-blocker status as gnome-boxes is not in the default install or live desktop package set for Beta RC3, adamw confirms the desktop live image boots with no virbr0 interface and networking works
21:38:55 <nirik> ack
21:38:58 <j_dulaney> ack
21:40:04 <brunowolff> ack
21:40:17 <adamw> #agreed this bug can be demoted to non-blocker status as gnome-boxes is not in the default install or live desktop package set for Beta RC3, adamw confirms the desktop live image boots with no virbr0 interface and networking works
21:41:22 <adamw> #topic other blockers
21:41:31 <adamw> so there's three we didn't discuss specifically, all of which have fixes in RC3
21:41:57 <adamw> we should confirm those are fixed, but i'm pretty sure they are. well, all except preupgrade...we can't really be confident there's no more bugs in preupgrade, i guess. :/
21:43:15 <j_dulaney> Hmm
21:43:33 <adamw> #info three other blockers are addressed in RC3 but need re-confirmation: #808499, #809052, #809342
21:43:42 <adamw> anyone want to go into any of those in detail?
21:45:20 <rbergeron> beyond "we do'nt know they're fixed" ? :)
21:45:39 <adamw> i just confirmed #809052 is okay.
21:46:01 <brunowolff> Are you proposing delaying the final decision until the rediness meeting to give time for more tsting?
21:46:04 <adamw> i have a high degree of confident in #809342 but i need to reboot my desktop to test that one (i was getting through all the tests i can do in a VM before doing the ones on metal).
21:46:14 <adamw> we didn't get to that point yet
21:47:01 <adamw> #808499 is more worrying; not that bug in itself, it probably is fixed, but the thing is, we haven't yet had a substantial preupgrade test at all because there's always been a bug which completely kills preupgrade in all our composes; so it's certainly possible there are more preupgrade bugs we haven't exposed yet
21:48:28 <adamw> that's what i've got on blockers, i guess.
21:48:33 <rbergeron> there are no more readiness meetings.
21:48:45 <rbergeron> There is only one for everything else.
21:49:50 <adamw> rbergeron: where do you want to go next?
21:50:12 <rbergeron> Well, we're basically waiting on validations, right?
21:50:16 <rbergeron> rest of the test matrix?
21:50:26 <rbergeron> We should look at that, I suppose.
21:50:31 <adamw> yeah. if you want a matrix status, said status is obviously 'not complete'.
21:50:38 <rbergeron> Right.
21:50:46 <rbergeron> What's the ETA assuming "we don't find a giant problem"
21:51:21 <adamw> eh, few hours, i guess?
21:52:23 * j_dulaney is testing away
21:52:43 <kalev> adamw: regarding the preupgrade tests, ask dgilmore to do a stable push with the latest builds that were included in RC3, so it's possible to test preupgrade with new anaconda?
21:53:36 <adamw> kalev: done already
21:53:42 <rbergeron> well, do we want to reconvene at, say, 7pm pacific?
21:53:44 <rbergeron> 6pm pacific?
21:53:49 <rbergeron> and finish the meeting?
21:53:50 <adamw> well, i asked
21:54:01 <adamw> it might help if someone could karma https://admin.fedoraproject.org/updates/anaconda-17.18-1.fc17
21:54:06 <adamw> rbergeron: wfm
21:55:31 * nirik should be around then.
21:55:47 <rbergeron> okay.
21:56:06 <rbergeron> #agreed will reconvene in 3hrs 5m, 6pm pacific, for status update.
21:56:37 <rbergeron> I'll keep my eye on the channel in case 400 people suddenly bomb the channel with help and we are done in an hour.
21:57:04 <rbergeron> Or you guys can not wait on me if there are enough people with consensus that testing is done and we are good.
21:57:16 <adamw> you optimist.
21:57:23 <adamw> if anyone wants to help out with the tests, please do. there's a lot to do.
21:57:25 <rbergeron> #topic Reconvening at 6pm pacific.
21:58:37 <robatino> that would be 0100 UTC Apr. 5
22:00:40 <rbergeron> #topic Reconvening at 6pm pacific (0100 UTC Apr. 5)
22:00:46 <rbergeron> robatino: u haz the power of the chair too :)
22:01:05 <robatino> i don't know how to use it
22:01:17 <robatino> or exactly what it means, for that matter
22:03:35 <j_dulaney> You can do things such as:
22:03:49 <j_dulaney> #info that would be 0100 UTC Apr. 5
22:03:59 <j_dulaney> Or
22:04:19 <j_dulaney> #info 2100 Eastern
22:04:30 <robatino> is there a link for all the commands?
22:05:08 <j_dulaney> Search the Wiki for meetbot
22:07:23 <robatino> found this: https://fedoraproject.org/wiki/Zodbot#Meeting_Functions
22:08:02 <robatino> this is more specific, though: http://wiki.debian.org/MeetBot
22:08:04 <robatino> thanks
22:37:01 <j_dulaney> adamw:  Pingety
22:38:46 <adamw> yo
22:39:23 <j_dulaney> adamw:  Can we do a test criteria that says that X can't keep crashing
22:39:40 <adamw> that would be 'workable desktop'. but it sounds system specific.
22:40:26 <j_dulaney> I reference the recent thread about X crashing
22:40:30 <j_dulaney> On Test
22:40:38 <j_dulaney> If you want, I can dig it up
22:41:45 <j_dulaney> Anyway, X just crashed in my VM
22:41:47 <j_dulaney> again
22:42:14 <j_dulaney> It also crashes fairly regularly on bare metal on a box where once upon a time it didn't
22:43:38 <adamw> really X? or shell?
22:44:02 <adamw> i haven't had any X crashes in VMs.
22:44:12 <j_dulaney> X
22:44:30 <j_dulaney> I say X because it seems to be pretty DE agnostic
22:44:43 <j_dulaney> Although it happens a little more often with G3
22:44:53 <j_dulaney> Clouding up
22:45:51 <adamw> like i said, i haven't seen any X crashes in VMs.
22:46:03 <adamw> well, except the one where it crashes when you swithc to a VT. that's been happening forever.
22:47:05 <adamw> qxl? cirrus?
22:48:05 <j_dulaney> qxl
22:48:24 <j_dulaney> Although it happens to my F17 bare metal install quite frequently, as well
22:49:16 * j_dulaney doesn't want to reboot atm since he is downloading YAITT
22:49:33 <j_dulaney> YAITT = Yet Another Image To Test
22:50:39 <adamw> j_dulaney: well, if you want to propose one, you can throw it on the list and cite the 'boot to a working desktop' criterion
22:50:54 <j_dulaney> If it happens again, I will
22:51:23 * j_dulaney doesn't want to cause us to block, but it is really getting ridiculous
22:52:13 <j_dulaney> Normally I consider Fedora to be stable enough by this point to use for every day work; I'm afraid to do anything with F17 involving critical data or lots of work
22:52:31 * nirik is having no problems here day to day... on bare laptop tho
22:53:41 <j_dulaney> Others have hit it, so I'm not the only one
22:53:49 <adamw> i haven't had an X crash on here for days either
22:53:50 * j_dulaney looks for the M/L thread
22:54:06 <adamw> or in any of the seven thousand VMs i've booted the last few days, heh
22:54:28 <adamw> damn, these bloody vnc tests are taking forever
23:00:25 <j_dulaney1> http://lists.fedoraproject.org/pipermail/test/2012-March/106291.html
23:00:37 <j_dulaney1> Wow, that is quite a storm brewing out there
23:02:53 <adamw> j_dulaney1: you said in the thread you get it with 16 as well...
23:03:09 <j_dulaney1> adamw:  Indeed
23:03:30 <adamw> did it _used_ to happen with 16?
23:04:54 <j_dulaney1> adamw:  No
23:05:32 <adamw> j_dulaney1: well X hasn't changed much in 16
23:05:39 <adamw> so it can only really be a kernel issue, i guess?
23:05:44 <adamw> try dropping to a 3.2 kernel and see if it happens
23:05:47 <adamw> in 16
23:05:50 <adamw> hell, or 17...
23:06:12 <j_dulaney1> adamw:  rgr
23:06:21 <j_dulaney> Better
23:06:47 <adamw> heh
23:09:10 <j_dulaney> Let's see how fast this install can go
23:09:54 <j_dulaney> Hmm Firefox seems to have crashed
23:13:06 <j_dulaney> And, Anaconda just died in the middle of copying crap to the virtual image
23:16:25 <adamw> you're not allowed to touch things any more.
23:17:14 <j_dulaney> Why not?
23:17:24 <adamw> you break them. =)
23:17:24 <j_dulaney> It's not my fault things are breaking!
23:17:38 <j_dulaney> I thought that was my job?
23:17:46 <adamw> not at this point
23:17:50 <adamw> it's your job to say everything is working
23:17:52 <adamw> lie if necessary!
23:17:53 <adamw> :P
23:18:27 <j_dulaney> Do I get a raise if I do this?
23:19:32 <adamw> you get a 10000% raise
23:19:42 <j_dulaney> Hmm
23:19:49 <j_dulaney> Sounds fair
23:20:12 <j_dulaney> 10000% of $0 ... Hey, wait!
23:20:21 <adamw> too bad, you agreed
23:20:49 <j_dulaney> Did not!
23:21:49 <j_dulaney> Trying again
23:21:52 <adamw> i have your signature right here
23:21:58 <adamw> *hastily forges signature*
23:22:07 <j_dulaney> Why must Anconda reboot the box when it quits?
23:22:15 <j_dulaney> I contest that!
23:22:27 <adamw> people complain when it doesn't.
23:22:59 <j_dulaney> Why?
23:23:52 <j_dulaney> Is yourmom a good root password?
23:29:07 <adamw> man, we're nearly there
23:29:33 <j_dulaney> Got further this time
23:29:37 <adamw> if anyone wants to do the finicky little tests nfs_variation and kickstart_file_path that'd really help
23:29:42 <j_dulaney> Maybe last time was a whacky fluke
23:30:13 <j_dulaney> Looks like I'm stuck here, now
23:30:14 <adamw> nfs_variation requires access to an nfs server with an exploded tree. well...i guess i could loop mount an ISO and share it via nfs. hum.
23:30:26 <j_dulaney> Raining so hard I can't see but a foot out the window
23:34:33 <j_dulaney> adamw:  I'll do the Kickstart test
23:37:11 <adamw> j_dulaney: thanks
23:37:22 <adamw> it's just a bit of an annoying one as you have to jam a kickstart into the initrd or smth
23:38:35 <j_dulaney> Indeed
23:39:08 <j_dulaney> I'm pulling out the kickstart file for the VM I just successfully installed
23:59:54 <j_dulaney> Hmm, halfway through package download decided to die
00:00:15 <j_dulaney> But, it seems the kickstart injection succeeded and install did start
00:00:23 <adamw> you got a clearly kickstarted install?
00:00:28 <adamw> it skipped all the stages it should have skipped?
00:01:04 <j_dulaney> Indeed
00:01:04 <adamw> sounds like a pass...
00:01:16 <adamw> when you say it's dying, is this the X server crapping out thing?
00:01:17 <j_dulaney> It just failed halfway through package install, said it ran out of mirrors
00:01:18 <adamw> or something else?
00:01:22 <adamw> oh.
00:01:26 <adamw> stale bloody mirrors again, i'll warrant
00:02:14 <adamw> i haven't had any issues like that either, but i've only been doing minimal netinstalls
00:02:20 <adamw> saves time
00:03:02 <kalev> or perhaps just packages that haven't been pushed to stable (to mirrors) yet, when the kickstart was based on the packages from media install?
00:04:09 <kalev> ah never mind, I guess no package versions specified in the kickstart files so it can't be that
00:05:47 <adamw> yeah.
00:05:58 <adamw> autogenerated kickstarts usually just specify package groups anyhow.
00:06:04 <adamw> unless you went in and did package customization.
00:06:37 <adamw> kalev: what are you doing hanging around here making smartass comments when you could be doing desktop validation, anyhow? ;)
00:08:09 <kalev> woops, I'll better pretend I'm not here :)
00:09:00 <kalev> and hey, I did confirm that my own fix to spin-kickstarts worked!
00:12:27 * adamw appeasr to have done 36 validation tests so far.
01:00:21 <rbergeron> #topic 0100 UTC / 6pm checkin.
01:00:26 <adamw> yo
01:00:31 * adamw frazzle
01:00:32 <rbergeron> hi
01:00:37 * rbergeron huggles
01:00:49 <adamw> so, we're close to done
01:00:51 <adamw> no new blockers really
01:01:16 * nirik waves
01:01:53 <rbergeron> right
01:02:31 * brunowolff is here
01:02:31 <adamw> i can't in all conscience say 'go' now
01:02:40 <rbergeron> Just want to check in in another 30m?
01:02:49 <adamw> needs longer than that :/
01:02:54 <adamw> i have a badminton appointment
01:02:59 <rbergeron> I don't want to waste time yapping about how we're not ready to meet unless we're realllly not ready to meet for like 24h
01:03:00 <adamw> and we need to wait to do a preupgrade test
01:03:15 <adamw> we need ~4hrs for a compose before we can test preupgrade
01:03:30 <adamw> preupgrade is frankly the only thing i have any worries about any more
01:03:34 <nirik> I've pushed anaconda/lorax and mesa to stable and started a branched compose.
01:03:35 <adamw> the rest is just box filling i think
01:03:43 <adamw> but preupgrade is terra incognita to be honest
01:03:48 <rbergeron> okay
01:03:55 * nirik hopes he didn't mess anything up that dgilmore will need to kill him for. ;)
01:04:22 <brunowolff> nirik has been sticking his neck out a lot lately.
01:04:51 <nirik> ;)
01:07:12 <rbergeron> okay, so, what's the scoop as far as regrouping? 10pm pacific? tomorrow morning?
01:07:28 <adamw> tomorrow i think
01:07:34 <adamw> we have a pretty solid chance we can ship this t hing
01:07:45 <adamw> but preupgrade is still a potential banana skin
01:07:54 <adamw> and it's going to take time to check the rest of teh boxes, i have efi and usb tests to  do
01:08:13 <adamw> i don't think we need to slip now, though. rc3 is holding up so far
01:08:18 <adamw> if preupgrade works we're good
01:08:20 <rbergeron> yar
01:09:19 * adamw will be out till 10-11 then back box ticking
01:09:37 <rbergeron> my main concern is letting others know we are go in time before people jet off for easter/good friday/or whatever.
01:09:41 <rbergeron> adamw: go :)
01:09:48 <adamw> got 5 mins to do one more test
01:09:51 * adamw is on bios raid
01:10:13 <rbergeron> do we want to leave this open meeting running till tomorrow morning or close out and give a time to regroup tomorrow
01:10:29 * adamw doesn't care
01:10:51 <adamw> oh, the only moderately important bug that's shown up this afternoon is that ntfs resizing is broken
01:10:56 * rbergeron doesn't either, but probably need a time to regroup anyway
01:10:59 <adamw> but i don't think that's even worth proposing as a blocker. resize itself works, i tested ext4
01:13:56 <adamw> any time tomorrow am works for me
01:14:00 <adamw> or late late tonight
01:14:15 <adamw> i suspect the two are going to be the same thing, for me...
01:14:41 <rbergeron> i had a short name from 2 to 4am today too
01:14:43 <adamw> ok, bios raid passes, and i'm out, back later
01:14:44 <rbergeron> nap
01:14:47 <rbergeron> even
01:14:56 <rbergeron> well, want to go for 8am?
01:15:25 <adamw> sure
01:15:28 <adamw> cya
01:15:36 <rbergeron> okay
01:16:14 <rbergeron> 8am pac, 11am est, ... I want to say that's 1500 UTC
01:16:23 <rbergeron> I'll float that for a few minutes and make it so if nobody objects
01:20:14 <rbergeron> #agreed We will regroup Thursday at 8am pacific, 11am eastern, 1500 UTC (Apr. 5)
01:20:58 <rbergeron> #info Just waiting on being able to test preupgrade, testing/validation is holding up so far, feeling reasonably good.
01:21:38 <rbergeron> Closing out in uno minute-o.
01:28:42 <rbergeron> #endmeeting