21:02:12 <rbergeron> #startmeeting F16 Beta Go/No-Go Meeting
21:02:12 <zodbot> Meeting started Wed Sep 21 21:02:12 2011 UTC.  The chair is rbergeron. Information about MeetBot at http://wiki.debian.org/MeetBot.
21:02:12 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
21:02:21 <rbergeron> #meetingname F16 Beta Go No-Go Meeting
21:02:21 <zodbot> The meeting name has been set to 'f16_beta_go_no-go_meeting'
21:02:28 <rbergeron> #topic Gathering Bodies and Minds
21:02:30 <rbergeron> who's here?
21:02:32 * nirik waves.
21:02:34 * jsmith is here!
21:02:38 * tflink is present
21:02:41 * athmane around
21:03:09 <rbergeron> dgilmore anywhere?
21:03:39 <rbergeron> Well, we'll proceed.
21:03:53 <rbergeron> #topic Why are we here?
21:04:00 <rbergeron> "You know the answer, just as I did"
21:04:05 <rbergeron> Oh, that's a movie.
21:04:09 <rbergeron> #info The purpose is to decide whether the Final release criteria have been met
21:04:21 <rbergeron> #info NO.
21:04:22 <rbergeron> #undo
21:04:22 <zodbot> Removing item from minutes: <MeetBot.items.Info object at 0xaa97ecc>
21:04:23 <rbergeron> #undo
21:04:23 <zodbot> Removing item from minutes: <MeetBot.items.Info object at 0xe341c8c>
21:04:34 <rbergeron> #info The purpose is to decide whether the *beta* release criteria hav ebeen met.
21:04:47 * rbergeron is tired.
21:04:58 * dgilmore will only be here for 10 minutes
21:05:13 <rbergeron> #link http://fedoraproject.org/wiki/Fedora_16_Beta_Release_Criteria
21:05:24 * satellit_ listening
21:05:29 <rbergeron> #chair adamw tflink jsmith dgilmore
21:05:29 <zodbot> Current chairs: adamw dgilmore jsmith rbergeron tflink
21:05:46 <rbergeron> So.
21:05:48 <rbergeron> #chair adamw
21:05:49 <zodbot> Current chairs: adamw dgilmore jsmith rbergeron tflink
21:05:53 <rbergeron> let's talk blocker bugs, first.
21:06:02 <rbergeron> #topic Remaining Blocker Bugs
21:06:14 <rbergeron> #link https://fedoraproject.org/wiki/Current_Release_Blockers
21:06:34 <rbergeron> I see three proposed... and at least one in new.
21:06:52 <rbergeron> adamw, tflink: this looks obviously no-goish at this point, but can we get some info?
21:06:53 <tflink> three proposed?
21:06:57 <adamw> the new one is actually fine
21:07:01 <tflink> I count 6
21:07:02 <adamw> it would be fixed in rc2
21:07:13 <adamw> the big outstanding problem bugs are:
21:07:20 <adamw> http://bugzilla.redhat.com/show_bug.cgi?id=738803
21:07:27 <rbergeron> oh, right, and two in assigned.
21:07:32 <adamw> http://bugzilla.redhat.com/show_bug.cgi?id=737731
21:07:39 <rbergeron> and 2 in assigned in proposed.
21:07:41 <adamw> and http://bugzilla.redhat.com/show_bug.cgi?id=738964
21:07:47 <adamw> which should be accepted, not proposed
21:07:59 <rbergeron> #info Big outstanding bugs are 738803, 737731, 738964.
21:08:28 <rbergeron> Do we want to go through them real quick and move them to accepted blockers?
21:08:29 <adamw> we have fixes for 738803 and 738964 but they have only landed very recently and we haven't even managed to do a compose with them yet
21:08:41 * nirik wonders if 740280 should be a beta blocker... it's on final now
21:08:44 <adamw> only 738964 is proposed, and i believe we actually voted to accept it, just didn't update it...
21:08:54 <tflink> did I miss that one?
21:09:00 * tflink checks logs
21:09:08 <adamw> nirik: by the comment, no.
21:09:39 <nirik> (if we pull the dracut update, no?)
21:09:55 <rbergeron> #info we have fixes for 738803, 738964, but landed recently and we dont' have a compose with them yet.
21:10:03 <adamw> no, we never had the version with no /dev/live in f16 beta tree, afaics.
21:10:03 <tflink> adamw: the last meeting we left it as not enough info
21:10:17 <adamw> tflink: oh, kay. well, i'm +1, based on our understanding of it now.
21:10:20 <nirik> adamw: ok.
21:10:22 <tflink> same here
21:11:35 <rbergeron> tflink, adamw: is that 738964? (/me encourages everyone to use the power of their chair-age)
21:11:43 <adamw> nirik: i just asked for info, but i'm pretty sure the dracut we have in the beta compose pile doesn't have the bug.
21:11:45 <adamw> rbergeron: yes
21:11:52 <adamw> #topic http://bugzilla.redhat.com/show_bug.cgi?id=738964
21:12:14 <tflink> #info Unable to make system bootable due to bootloader choice
21:12:17 <adamw> this is a nasty bug which took us quite a while to pin down: basically, the introduction of gpt disk labels in f16 causes some problems with the bootloader install logic
21:12:20 <tflink> #link https://bugzilla.redhat.com/show_bug.cgi?id=738964
21:13:06 <tflink> there is a non-well publicised fix in the form of an updates image
21:13:15 <adamw> which we're currently testing
21:13:20 <tflink> but I think that we're waiting for verification that liveinstall from usb still works
21:13:24 <adamw> but, obviously, that's not gonna make release this week.
21:13:42 <tflink> yeah, even if we did get a build today, I'd want to see more testing
21:13:51 <adamw> the practical impacts of this depend on exactly what disks you have connected and what partitioning method you choose, but all of them kinda suck
21:14:24 <adamw> not able to install the bootloader where you want, bootloader installed to a random usb stick you had plugged in, bootloader installed to the wrong disk overwriting the working one you had before, bootloader installed to the USB stick you're installing from...
21:14:26 <adamw> it's just icky.
21:14:33 * nirik was again thinking we should have go/no-go on thursdays, but I suppose it's not possible to change that this cycle anyhow. ;(
21:14:47 * dgilmore needs /me needs to run
21:14:53 <adamw> the fix, unfortunately, is quite heavy - anaconda will now stick a bios boot partition on any gpt-labelled disk it finds, as long as there's 1MB of space on it - so that's going to need some serious testing
21:15:03 <rbergeron> nirik: but then would we just wind up saying, "we should do this friday" ?
21:15:39 <nirik> :) yeah, it's a slippery slope... but I don't think as much time is needed for mirror syncing anymore...
21:15:45 <adamw> nirik: honestly, i'd want to slip even if we had a day. we're really gonna need to be careful with the anaconda change.
21:15:58 <tflink> +1
21:16:03 <jsmith> +1
21:16:04 <nirik> yeah, understood... just saying. ;)
21:16:21 <adamw> so, everyone's +1 blocker on this?
21:16:26 <rbergeron> +1
21:16:31 <nirik> yeah, +1 sadly
21:16:36 <rbergeron> yes, sadface
21:16:53 <jsmith> I'd rather we slipped than took the risk of messing up people's data
21:17:02 <jsmith> (even if it's just the bootloader)
21:17:15 <rbergeron> okay. So - is that the *only* thing seriously blocking us at this point?
21:17:19 <rbergeron> (Other than, need to test, etc)
21:17:26 <dgilmore> im +1 for blocker
21:17:28 <tflink> proposed #agreed - 738964 - AcceptedBlocker - This can cause lots of problems with existing disks and installations. The fix needs quite a bit of testing by nature
21:17:30 * dgilmore really runs
21:17:37 <jsmith> The repoclosure problem is blocking us as well, right?
21:17:40 <adamw> rbergeron: no
21:17:47 <tflink> rbergeron: preupgrade is also an issue
21:18:05 <adamw> jsmith: the repoclosure issue has a fix, though it's not obvious from the current blockers page
21:18:11 <adamw> it just needs to pull in one specific update
21:18:11 * rbergeron is just eliciting as much info as possible at this point in as orderly a way as possible so everyone is on the same page as to level of breakage / priority.
21:18:18 <adamw> that one i'm not worried about, we'd be on top of it for the next spin
21:18:33 <adamw> tflink: ack
21:18:41 <adamw> agree on this bug, then we'll discuss the others
21:19:07 * nirik is still sadly +1
21:19:08 <jsmith> ACK on tflink's proposal
21:19:12 <tflink> #agreed - 738964 - AcceptedBlocker - This can cause lots of problems with existing disks and installations. The fix needs quite a bit of testing by nature
21:19:16 <adamw> okay
21:19:27 <adamw> #topic http://bugzilla.redhat.com/show_bug.cgi?id=738803
21:19:38 <adamw> this is the one we've been stuck on most of the time - selinux denials booting the live image
21:19:52 <adamw> we finally have a fix for it, but it only landed in working form this morning, again much too late to make the schedule
21:20:18 <adamw> this one just turned out to be icky to identify and fix, it pinged back and forth between kernel and selinux, and there was another bug complicating matters (actually, two other bugs...)
21:20:21 <tflink> #link https://bugzilla.redhat.com/show_bug.cgi?id=738803
21:20:30 <tflink> #info SELinux denial(s) prevent(s) gnome-shell from starting on F16 Beta RC1
21:21:23 <adamw> mgrepl and dwalsh both gave it a good shot to fix it in time but in the end we couldn't manage it
21:22:04 <nirik> so, hopefully we have fixes for both those soon and new rc later today/tomorrow?
21:22:13 <adamw> pretty much, one more bug to flag up
21:22:25 <adamw> #topic http://bugzilla.redhat.com/show_bug.cgi?id=737731
21:22:50 <adamw> so this is similar to a bug that's fixed: it's to do with installing a new grub2 bootloader on upgrade
21:23:14 <adamw> on an anaconda-based update, it pops up a dialog asking you what to do with the bootloader - we changed the default choice there to be more sensible, and kinda assumed preupgrade would use the new default
21:23:34 <adamw> turns out it doesn't; preupgrade writes a bootloader line into the ks it feeds to anaconda, asking it to update the existing bootloader, which isn't possible for f16
21:23:40 <adamw> so we need preupgrade to be changed
21:24:17 <tflink> #link https://bugzilla.redhat.com/show_bug.cgi?id=737731
21:24:21 <adamw> so, i feel like that's a bit of a qa fail, but we had the other bugs anyway, so it wouldn't have made much of a difference. but we should've investigated more carefully.
21:24:26 <tflink> #info Bootloader is left in F15 configuration when preupgrading to F16
21:24:57 <adamw> (also, the fix will be in f15's preupgrade, so we have the 'slack' time to fix it, we don't need to fix it in time for f16 image compose
21:25:56 * nirik doesn't see any comments from maintainer there, hopefully it's on his radar.
21:26:18 <adamw> nirik: i only just identified the issue there, so hughsie hasn't had much time.
21:26:22 <adamw> i'm sure he'll get on it.
21:26:24 <nirik> yeah.
21:26:41 <adamw> #topic http://bugzilla.redhat.com/show_bug.cgi?id=735866
21:26:48 <adamw> oh, we also have this one hanging around
21:26:51 <adamw> the udevadm settle bug
21:26:54 <rbergeron> LOL
21:26:56 <rbergeron> "hanging around"
21:26:58 <adamw> but i'm kinda souring on this one as a blocker
21:27:12 <adamw> as it doesn't seem to happen to anyone *super* often, and no-one's come up with an explanation yet; it may be multiple bugs
21:27:22 <adamw> we could probably just go with a commonbugs note for it
21:27:25 <tflink> #link https://bugzilla.redhat.com/show_bug.cgi?id=735866
21:27:34 <tflink> #info boot hangs with udevadm settle - timeout of 120 seconds
21:27:34 <adamw> rbergeron: just got no developer traction on it
21:27:41 <adamw> i've pinged harald and kay a few times and got nothin' back
21:27:58 <rbergeron> are they still travelling? /me wonders
21:28:20 <adamw> no, back since two days ago i believe
21:28:56 <adamw> i did get a passing mention from kay that udevadm settle hanging is 'usually' due to buggy kernel modules
21:29:14 <rbergeron> so you're souring on it staying a blocker?
21:29:21 <adamw> i am a bit, yeah.
21:29:21 <rbergeron> or souring on it as in peeved that it's going nowhere
21:29:30 <adamw> both? :)
21:29:30 * rbergeron looks for other opinions?
21:29:38 <adamw> yeah, anyone else got a take on it?
21:29:42 <nirik> going nowhere 120seconds at a time? ;)
21:29:44 <adamw> heh
21:29:47 <rbergeron> LOL
21:29:53 <adamw> i don't think anyone's come out and said it happens to them EVERY boot yet
21:30:02 <tflink> I'm pretty much of the same mind here - we haven't been seeing it all the time
21:30:03 <adamw> and since the only 'blocker' impact is on the live installer, 'reboot a couple times' isn't a horrible workaround
21:30:06 <rbergeron> nirik: going nowhere 120 seconds at a time to 10,000 leagues under the sea
21:30:06 <tflink> and not much traction
21:30:07 <nirik> I guess I'd be ok demoting it to a NTH... but continue to try and get somewhere with it.
21:30:33 <tflink> in my mind the question is - would we hold release up until we had a fix for this?
21:30:49 <jsmith> Do we have an idea of what percentage of installs hit it?
21:30:50 <tflink> if it was the only blocker left
21:31:03 * nirik re-skims the bug
21:31:03 <adamw> jsmith: not really, we didn't get a lot of data
21:31:12 <adamw> jsmith: i haven't seen other people reporting it on list or forums or other bugs either
21:31:18 * jsmith hit it
21:32:17 <rbergeron> how related do we think it is to 734096? has fixing that changed anything? or unknown at this point
21:32:43 <rbergeron> although harald said it's likely unrelated
21:33:09 <adamw> i wouldn't guess super related...
21:33:14 <adamw> oh, i see https://bugzilla.redhat.com/show_bug.cgi?id=670964 from f14, similar issue.
21:33:27 <adamw> jsmith: how often do you hit it?
21:34:28 <jsmith> adamw: I hit it a few times in a row, but I don't remember what image I hit it with
21:34:52 <adamw> can you boot the rc1 desktop live a few times and see if you hit it?
21:34:56 <jsmith> adamw: (I was also hitting selinux issues as well, so it was hard to tell which hangs were udev related and which were selinux)
21:35:01 <jsmith> adamw: Will do
21:35:07 <adamw> with enforcing=0 to exclude selinux
21:36:07 * jsmith plays the "Gee, I wonder what data this USB key holds" game
21:36:10 <rbergeron> okay, so in the meantime: do we want to NTH this one? or wait and see how testing goes for a day or two
21:36:34 * rbergeron prods us along
21:36:43 <adamw> let's punt till friday
21:36:53 <adamw> but i'm gonna be -1 blocker friday unless there's more data
21:37:01 <rbergeron> okay.
21:37:13 <tflink> same here, might as well wait for friday
21:37:27 <rbergeron> #info will make final call on 735866 staying as blocker or not on friday
21:37:46 <adamw> shall we go through the proposed list quickly?
21:37:49 <adamw> most of them are -1s
21:37:50 <rbergeron> yes please.
21:38:10 <adamw> #topic https://bugzilla.redhat.com/show_bug.cgi?id=737774
21:38:37 <tflink> adamw: that's already accepted
21:38:48 <adamw> doesn't have a whiteboard
21:38:48 <tflink> it blocks the repoclosure issue
21:39:14 * tflink didn't think that a blocker of a blocker needed accepted
21:39:16 <tflink> my mistake
21:39:55 <tflink> I'm +1 on this, it's a repoclosure issue
21:39:59 <rbergeron> shall we accept it then? :)
21:40:02 <adamw> well
21:40:03 <tflink> +1 blocker, that is
21:40:09 <adamw> if we leave it blocking f16beta, we should give it acceptedblocker
21:40:13 <jsmith> +1 blocker from me
21:40:14 <adamw> or we can just stop it blocking f16beta in its own right
21:40:19 <nirik> +1.
21:40:24 <adamw> oh wait, it doesn't. sigh.
21:40:27 <adamw> anyway. moving on
21:41:05 <adamw> #agreed 737774 is a blocker
21:41:09 <adamw> close enough!
21:41:13 <adamw> #topic https://bugzilla.redhat.com/show_bug.cgi?id=739258
21:41:27 <tflink> #link https://bugzilla.redhat.com/show_bug.cgi?id=739258
21:41:38 <tflink> #info Graphical firstboot runs, even if /etc/sysconfig/firstboot has RUN_FIRSTBOOT=NO
21:41:56 <adamw> this is a jsmith special ;)
21:41:59 <adamw> i couldn't reproduce this at all
21:42:04 <jsmith> Yeah...
21:42:07 <rbergeron> LOL
21:42:09 <adamw> could anyone else?
21:42:10 <jsmith> I can still hit it
21:42:11 * rbergeron snickers
21:42:36 <adamw> jsmith: if you just run firstboot on a booted live image what happens?
21:42:37 <jsmith> Essentially, firstboot-graphical.service and firstboot-text.service were both enabled on the Live image
21:43:00 <jsmith> adamw: I'll double-check for you :-)
21:43:08 <adamw> jsmith: they're known to be enabled
21:43:37 <tflink> I don't think that I've seen firstboot on any livecd boot
21:43:40 <adamw> but the RUN_FIRSTBOOT=NO should cause the firstboot process itself to just shut down right away
21:43:48 <adamw> and apparently for everyone else it does ;)
21:44:03 <adamw> i have a hard time seeing how it couldn't, as the check is in firstboot's code, i can't see how that file could exist and firstboot could still proceed
21:44:51 <jsmith> adamw: Booting that up now
21:45:32 <adamw> oh wait, you have to run /etc/init.d/firstboot start , not just firstboot directly
21:45:56 <jsmith> adamw: OK, I'll do that -- just as soon as I get past the udevsettle delay :-/
21:45:59 <adamw> /etc/init.d/firstboot says:
21:46:03 <adamw> FILENAME=/etc/sysconfig/firstboot
21:46:04 <adamw> ..
21:46:11 <adamw> if [ -f $FILENAME ] && [ ! -z "$(grep 'RUN_FIRSTBOOT=NO' $FILENAME)" ]; then
21:46:11 <adamw> exit 0
21:46:11 <adamw> fi
21:46:14 <adamw> so...it's kinda...there.
21:46:44 <jsmith> Is there both a sysv-style initscript and systemd units?
21:46:55 <adamw> the systemd unit calls /etc/init.d/firstboot start.
21:46:57 * jsmith speaks bad grammar
21:47:02 <jsmith> Ah...
21:47:24 <tflink> maybe do the same on this - leave it until friday, demote to NTH if no more info?
21:47:27 <adamw> yeah
21:47:35 * rbergeron nods
21:47:39 <adamw> i think that crack-smoking reporter should put down the pipe and figure out what he's doing wrong
21:47:41 <adamw> then we can downgrade it
21:47:42 <adamw> ;)
21:47:42 <rbergeron> LOL
21:47:45 <adamw> +1
21:47:49 <rbergeron> +1
21:48:05 <jsmith> +1... uh, I mean... no comment
21:48:07 <rbergeron> (to tflink's proposal and the crack-smoking reporter comment, lol)
21:48:22 <tflink> +1 to the leaving it til friday
21:48:34 <adamw> propose #agreed 739258: jsmith is sure about this one but no-one else can reproduce, ask jsmith to look into it more closely and re-evaluate on friday
21:48:40 <jsmith> Just for that, I'll build a new USB key from scratch and try again.
21:48:46 <tflink> ack
21:49:16 <adamw> #agreed 739258: jsmith is sure about this one but no-one else can reproduce, ask jsmith to look into it more closely and re-evaluate on friday
21:49:36 <adamw> 739591 is closed already...
21:49:51 <adamw> #topic https://bugzilla.redhat.com/show_bug.cgi?id=739345
21:50:08 <adamw> seems straightforward if we need the new fedora-logos.
21:50:08 <tflink> #link https://bugzilla.redhat.com/show_bug.cgi?id=739345
21:50:19 <tflink> #info pylorax throws an exception when used with fedora-logos-16.0.2
21:50:57 <tflink> IIRC, we do if we want the dark grey splash for syslinux
21:51:23 <tflink> if we use 16.0.1, the splashes will be black
21:51:30 <tflink> but lorax won't crash
21:51:54 <adamw> technically this is probably nth, as the artwork bug is nth
21:51:55 <tflink> I'm +1 blocker on this
21:52:06 * jsmith leans towards blocker
21:52:08 <adamw> but in practice it might be best to keep it blocker to make sure we don't screw up and pull the new logos but not the new pylorax
21:52:18 <tflink> you need to get both
21:52:22 <adamw> right
21:52:22 <jsmith> Right...
21:52:28 <tflink> if you pull in the new lorax and the old logos, it'll still crash
21:52:33 <adamw> ah
21:52:46 <tflink> the problem is in hard-coded paths in lorax
21:52:57 <adamw> yeah, i see
21:52:58 <tflink> if it doesn't find the right files, it throws an exception
21:53:05 <adamw> so of course you should've fixed them not to be hardcoded ;)
21:53:16 <adamw> let's keep it blocker, it makes things safer
21:53:47 <tflink> it's not like we'll get very far without getting this right :-D
21:53:51 <adamw> true
21:54:13 <adamw> propose #agreed 739345 is a blocker as it can make it impossible to generate DVDs
21:54:19 <adamw> s/DVDs/images
21:54:20 <tflink> ack
21:55:31 <nirik> ack
21:55:39 <rbergeron> ack
21:55:48 <adamw> #agreed 739345 is a blocker as it can make it impossible to generate images
21:56:14 <adamw> #topic https://bugzilla.redhat.com/show_bug.cgi?id=739910
21:56:26 <adamw> this one seems clearly -1 as the affected gnome-packagekit isn't actually in beta
21:56:28 <tflink> #link https://bugzilla.redhat.com/show_bug.cgi?id=739910
21:56:46 <tflink> #info gnome-packagekit fails when trying to update - The package id's '' are not valid
21:57:00 <tflink> as in the comments, I'm also -1 blocker, -1 NTH on this
21:57:18 * tflink needs to leave
21:57:48 * nirik is -1
21:57:59 <adamw> tflink: fly, my pretty
21:58:05 <adamw> anything you wanted to flag up for us?
21:58:28 <tflink> I don't think so, we've hit the big ones
21:58:34 <adamw> k
21:58:43 <rbergeron> Okay. Can we call this a no-go now?
21:58:49 <adamw> it clearly is
21:58:59 <adamw> but we do that at the end, right?
21:58:59 * tflink is still confused on 739253 since he can't see power options from gdm greeter but that isn't a blocker/noblocker issue
21:59:08 <adamw> tflink:  yeah, i'll note that detail
21:59:10 <smooge> no-go
21:59:50 <adamw> so, we're -1 on 739910? berge?
22:00:11 <jsmith> -1 from me
22:00:14 <adamw> that's 3!
22:00:22 <rbergeron> oh, i thought you said "we hit the big ones"
22:00:24 <rbergeron> -1
22:00:35 <rbergeron> sorry, i missed the link
22:00:35 <adamw> propose #agreed 739910 is not a blocker or nth as the affected gnome-packagekit is not in the beta frozen package set
22:01:22 <jsmith> ACK
22:01:47 <rbergeron> ack.
22:01:53 <adamw> #agreed 739910 is not a blocker or nth as the affected gnome-packagekit is not in the beta frozen package set
22:01:55 <nirik> aCk
22:02:19 <adamw> #topic https://bugzilla.redhat.com/show_bug.cgi?id=739253
22:03:11 <adamw> so the criteria require power management options presented by the desktop to work: "All release-blocking desktops' offered mechanisms (if any) for shutting down,
22:03:11 <adamw> logging out and rebooting must work"
22:03:53 <adamw> there's a couple of twists to this one: you could argue that doesn't cover the login manager (though really, we've always considered that it does), and some people are seeing gdm *not present* any pm options - which is not actually a blocker case...
22:03:54 <nirik> does that imply in the desktop?
22:03:55 * jsmith leans toward blocker on this one, but is worried about the lack of consistency in the feedback
22:04:10 <adamw> i think the good news is no-one's said that with 3.1.92 they got broken PM options
22:04:20 <adamw> they either get working ones or none - both of which are not blocker scenarios, heeh
22:04:59 <nirik> you would think it would offer poweroff all the time tho, no?
22:05:00 <adamw> but anyway - the original bug does look blockerish.
22:05:13 <adamw> nirik: you'd think, yeah. but if it doesn't...per the current criteria, we don't care.
22:05:22 <adamw> (though maybe we should.)
22:05:23 <nirik> yeah.
22:05:42 <adamw> i'm probably +1 blocker here, and try and plumb out what's going on with some people seeing options and others not
22:06:05 * nirik is +1 blocker, but would like to see if we can be more consistent in the solution...
22:06:54 <rbergeron> yeah, it worries me that everyone is having a variety of experiences
22:07:00 <rbergeron> +1
22:07:18 <nirik> how about +1 blocker to fix the real issue, and another bug to make it consistent for final?
22:07:37 <adamw> #agreed 739253 is a blocker per criterion "All release-blocking desktops' offered mechanisms (if any) for shutting down, logging out and rebooting must work"
22:07:45 <jsmith> Awesome :-)
22:07:48 <adamw> #topic https://bugzilla.redhat.com/show_bug.cgi?id=672023
22:07:58 <adamw> #action adamw to follow up on 739253 with halfline
22:08:18 <adamw> this feels more nth than blocker to me\
22:08:31 <nirik> 15?
22:08:35 <adamw> it's not like it means abrt doesn't submit the backtrace, just that it'll allow you to continue without one
22:08:41 <adamw> nirik: seems like this is an old bug that came back
22:08:44 <adamw> see the last couple of comments
22:08:53 <jsmith> Are there any criteria that this hits?
22:09:24 <adamw> not really
22:09:38 <jsmith> The comment says " proposing as a beta blocker since this can create a lot of noise in bz"
22:09:51 <jsmith> I'm not sure that's a current criterion
22:09:55 * nirik is ok with NTH, -1 blocker
22:10:00 <jsmith> So I'd personally say NTH, -1 blocker
22:10:36 <adamw> actually..do we really want to give it even nth?
22:10:48 <jsmith> Yeah, I think we do
22:10:59 <adamw> well, it'd only affect the live image really
22:11:19 <adamw> although actually, that's an important scenario i guess, because it's hard to get a full trace on the live...and we really don't want a ton of live reports with no trace
22:11:23 <adamw> so yeah...nth is good.
22:12:22 <adamw> propose #agreed 672023 does not hit any criteria, but it would be good to avoid getting crash reports from the live image with no trace: rejectedblocker, acceptednth
22:12:43 <nirik> ack
22:12:50 <jsmith> ACK
22:12:50 <rbergeron> ack
22:12:56 <adamw> #agreed 672023 does not hit any criteria, but it would be good to avoid getting crash reports from the live image with no trace: rejectedblocker, acceptednth
22:13:15 <adamw> okay, that's proposed blockers...there's one more bug dlehman had a question about
22:13:24 <jsmith> adamw: Let's discuss it!
22:13:34 <adamw> #topic https://bugzilla.redhat.com/show_bug.cgi?id=731549
22:13:58 <adamw> so this is about the message anaconda pops up when you need a BIOS boot partition but you haven't created one
22:14:05 <adamw> the original message was pretty hard to understand
22:14:09 <adamw> mo and i came up with a better one
22:14:31 <adamw> but we're past string freeze, and neither me, mo or dlehman really understands the implications of that - do we need to get an exception to change a message like this now?
22:15:14 <jsmith> No, but a heads up to the translation team would be nice
22:15:28 <adamw> okay
22:15:33 <jsmith> Just let them know that there will be a few strings that need to be updated in anaconda, and I think we'll be OK
22:15:41 * nirik nods.
22:15:41 <adamw> would it break anything for dlehman to just change the string and roll a new anaconda build?
22:15:44 <nirik> I think thats fine.
22:15:55 <jsmith> adamw: Just make sure he pushes the strings to tx.net after doing so
22:16:00 <adamw> okay
22:16:11 <adamw> we'll try and sort that out
22:16:22 <adamw> does he need to wait for translations before building the new anaconda package?
22:16:32 <jsmith> Might not hurt to ask on the translation list, just to make sure
22:16:44 <jsmith> If he doesn't wait for translations, they'll see that message in English
22:16:54 <adamw> okay
22:16:57 <nirik> https://admin.fedoraproject.org/mailman/listinfo/i18n
22:17:11 <adamw> thanks for the info
22:17:52 <jsmith> trans@lists.fedoraproject.org
22:18:16 <nirik> ah yeah, possibly better
22:18:22 <adamw> #action adamw and dlehman to co-ordinate fix for 731549 with i18n team
22:19:40 <adamw> i think that's all the bugs we need to discuss...
22:19:43 <adamw> anything i missed?
22:19:56 * rbergeron prays
22:20:21 * nirik has nothing more... is there a final 'no-go' vote? ;)
22:20:31 <rbergeron> That's next, if we are not missing bugs. :)
22:20:38 <adamw> let's move on quick!
22:21:30 <rbergeron> #topic Go/No Go
22:21:41 <rbergeron> So I think we're pretty much at a no-go.
22:21:47 <rbergeron> Agreed?
22:22:02 <adamw> qa votes no: there are outstanding unresolved blockers in the current candidate build
22:22:36 * jsmith votes "No Go"
22:22:45 <rbergeron> #info qa votes no, outstanding unresolved blockers in the current candidate build.
22:22:51 <rbergeron> #info jsmith, rbergeron also vote no-go.
22:23:08 <nirik> yeah, no-go. ;(
22:23:15 <rbergeron> Okay.
22:23:20 <jsmith> Rel-eng had to go, but on behalf of Dennis, I'll say no-go for him :-)
22:23:27 <rbergeron> #agreed We are a no-go for Beta.
22:23:33 <adamw> well, foo.
22:23:47 <rbergeron> #info We will regroup next Wednesday, same time, for another go/no-go, as well as having another blocker meeting Friday.
22:24:16 <rbergeron> #info Release readiness meeting will happen tomorrow as planned.
22:24:24 <rbergeron> Anything else?
22:24:32 <rbergeron> #action rbergeron to send out mail, notify, update the schedule.
22:24:49 <adamw> sorry about this one folks :( we took an extra week testing time but still didn't make it, sigh
22:25:25 <rbergeron> adamw: yeah, do we think that made a difference?
22:25:31 <rbergeron> Would we be slipping 2 weeks? :)
22:25:37 <adamw> it's certainly possible
22:25:38 <jsmith> rbergeron: I honestly think so
22:25:44 <adamw> i don't feel like we sat on our hands that extra week
22:25:45 <rbergeron> Okay. Just curious
22:25:47 * rbergeron nods
22:26:04 <rbergeron> okay. Well folks: Thanks for coming.
22:26:09 <rbergeron> See y'all next week.
22:26:16 <rbergeron> <grouphug>
22:26:28 <nirik> thanks everyone. Sorry it couldn't be better news. ;(
22:26:35 <rbergeron> #endmeeting