17:01:05 <tflink> #startmeeting F17-blocker-review
17:01:05 <zodbot> Meeting started Fri Jan 27 17:01:05 2012 UTC.  The chair is tflink. Information about MeetBot at http://wiki.debian.org/MeetBot.
17:01:05 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
17:01:14 <tflink> #meetingname F17-blocker-review
17:01:14 <zodbot> The meeting name has been set to 'f17-blocker-review'
17:01:21 <tflink> #topic roll call
17:01:33 <tflink> who's ready for some blocker bug review awesomeness?
17:01:37 * nirik is lurking around
17:01:39 <tflink> #chair adamw
17:01:39 <zodbot> Current chairs: adamw tflink
17:02:21 <adamw> yo
17:02:34 * adamw is blockerrific
17:03:16 * tflink has an image of tony the tiger saying "it's blockerrrrrrific!"
17:03:59 <adamw> that's the one
17:05:07 * tflink waits a bit more so we can hopefully have 3 people
17:08:06 <tflink> pschindl, jskladan: here to help with the blocker reivew?
17:08:16 <jskladan> tflink: just lurking :)
17:08:23 <adamw> we'll take that as a 'yes'
17:08:28 <tflink> :'(
17:08:49 <tflink> alrighty, it's almost 10 after. let's get this party started
17:09:03 <pschindl> tflink: I'm interested on what's going on here.
17:09:03 <tflink> #topic Introduction
17:09:19 <tflink> #info Our purpose in this meeting is to review proposed blocker and nice-to-have bugs and decide whether to accept them, and to monitor the progress of fixing existing accepted blocker and nice-to-have bugs.
17:09:34 <tflink> #link https://fedoraproject.org/wiki/QA:SOP_Blocker_Bug_Meeting
17:09:45 <tflink> #link https://fedoraproject.org/wiki/Current_Release_Blockers
17:09:56 <tflink> #info 5 proposed blockers
17:10:07 <tflink> #info 1 proposed nth
17:10:18 <adamw> oh yay, the pain will be short.
17:10:29 <tflink> unless there are any objections, I'm going to get started with the proposed blockers
17:10:41 <tflink> adamw: depending on the level of debate, yes :)
17:10:50 <tflink> #topic (696482) Protective MBR entry on GPT drives must be marked active for some machines to boot, but this is a violation of GPT spec
17:10:53 <tflink> #link http://bugzilla.redhat.com/show_bug.cgi?id=696482
17:10:54 <buggbot> Bug 696482: urgent, unspecified, ---, anaconda-maint-list, NEW, Protective MBR entry on GPT drives must be marked active for some machines to boot, but this is a violation of GPT spec
17:10:55 <tflink> #info Proposed Blocker, NEW
17:11:02 <adamw> oh, god, this one.
17:11:16 <tflink> like I said, depending on the level of debate ...
17:11:24 <adamw> i think i saw some discussion of this in #anaconda yesterday
17:11:52 * tflink has a machine that hits this
17:12:11 <tflink> it's supposed to be an EFI machine, too
17:12:56 <tflink> however, I'm not really sure what we can do on this without more input
17:13:11 <adamw> <bcl> yes, I'm working on fixing up mjg59's patch for that
17:13:12 <adamw> which is bug 754850
17:13:13 <buggbot> Bug https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=754850 unspecified, unspecified, ---, anaconda-maint-list, NEW, Some systems won't boot off GPT disks if the protective MBR entry isn't flagged bootable
17:14:05 <adamw> looks like they're going to go ahead and set the flag.
17:14:07 <tflink> does that mean that anaconda will set the MBR boot flag?
17:14:16 <adamw> yeah.
17:14:36 <adamw> so we can probably close the old bug as a dupe of the new one, since that's where the action is.
17:14:48 <jskladan> is that the #2 option of your comment in the 696482, adam?
17:14:50 <tflink> so it sounds like a fix is on the way
17:15:02 <maxamillion> o hai
17:15:11 <adamw> jskladan: indeed
17:15:30 <jskladan> maxamillion: http://2.bp.blogspot.com/_HEgnDdxt_5o/S5x1sGE_-3I/AAAAAAAAAy0/pDyugx5dh7M/s320/o+hai.jpg
17:16:18 <tflink> proposed #agreed 696482 - AcceptedBlocker - In most cases (see Blocker_Bug_FAQ), a system installed according to any of the above criteria (or the appropriate Beta or Final criteria, when applying this criterion to those releases) must boot to the 'firstboot' utility on the first boot after installation, without unintended user intervention, unless the user explicitly chooses to boot in non-graphical mode. This includes correctly accessing any encry
17:16:27 <maxamillion> jskladan: ha!
17:16:35 <tflink> ack/nak/patch?
17:16:48 <adamw> nack
17:16:56 <adamw> i just made it a dupe of 754850
17:17:01 <adamw> so we can make *that* one a blocker if we like
17:17:27 <tflink> proposed #agreed 754850 - AcceptedBlocker - In most cases (see Blocker_Bug_FAQ), a system installed according to any of the above criteria (or the appropriate Beta or Final criteria, when applying this criterion to those releases) must boot to the 'firstboot' utility on the first boot after installation, without unintended user intervention, unless the user explicitly chooses to boot in non-graphical mode. This includes correctly accessing any encry
17:17:37 <tflink> adamw: not sure they're dupes, though
17:17:53 <tflink> 754850 is a potential solution to 696482
17:18:08 <tflink> either way, though
17:18:12 <tflink> ack/nak/patch?
17:18:48 <jskladan> ack
17:19:03 <adamw> ack
17:19:12 <adamw> tflink: bcl said to make them a dupe, as 754850 is where the action's going to be.
17:19:20 <tflink> #agreed 754850 - AcceptedBlocker - In most cases (see Blocker_Bug_FAQ), a system installed according to any of the above criteria (or the appropriate Beta or Final criteria, when applying this criterion to those releases) must boot to the 'firstboot' utility on the first boot after installation, without unintended user intervention, unless the user explicitly chooses to boot in non-graphical mode. This includes correctly accessing any encrypted part
17:19:34 <tflink> adamw: I still don't agree but don't care enough to argue :)
17:19:46 <adamw> that's the qa spirit!
17:19:55 <tflink> #topic (742207) No usable bootloader option during a text mode f15->f16 upgrade
17:19:58 <tflink> #link http://bugzilla.redhat.com/show_bug.cgi?id=742207
17:19:59 <buggbot> Bug 742207: high, unspecified, ---, anaconda-maint-list, NEW, No usable bootloader option during a text mode f15->f16 upgrade
17:20:01 <tflink> #info Proposed Blocker, NEW
17:20:04 <adamw> oh, i'll secretaryize
17:20:14 <tflink> adamw: appreciated
17:20:37 <tflink> did we ever float a proposal to test@ regarding a release requirement around text-mode installs?
17:20:58 <maxamillion> pardon the noob question, I've been out of the bugzapper game for a while due to silly school stuff ... what's ack/nack/patch definitions?
17:21:13 <tflink> maxamillion: not sure what you're asking
17:21:33 <tflink> ack - ok with the proposal
17:21:38 <tflink> nak - not OK with the proposal
17:21:48 <adamw> tflink: i don't think we got to it yet.
17:21:54 <tflink> patch - change to proposal
17:22:00 <maxamillion> tflink: ah, ok ... perfect, thanks
17:22:05 <tflink> maxamillion: np
17:22:21 <adamw> tflink: i think it's on pschindl's todo list as part of the criteria concordance
17:22:34 <tflink> yeah, I haven't gotten all the way through that email yet
17:22:34 <adamw> we really need anaconda team's opinion on whether text mode upgrade is 'supported'
17:22:47 <tflink> we could go with "The installer must be able to complete an installation using the text, graphical and VNC installation interfaces"
17:23:02 <pschindl> I send a mail to anaconda-devel-list where I ask them for their meaning
17:23:16 <pschindl> * opinion
17:23:18 <tflink> I'd argue that bootloader issues make for an incomplete installation
17:23:20 <pschindl> sry
17:23:34 <adamw> tflink: this issue is upgrade specific
17:23:40 <adamw> tflink: fresh text install worked okay, we checked that
17:23:59 <adamw> pschindl: i don't see that mail - it may be stuck in moderation
17:24:08 <maxamillion> these are alpha blockers, yes?
17:24:11 <tflink> I remember seeing it, looking for a link
17:24:20 <adamw> ah i see it now
17:24:24 <adamw> didn't have 'text' in the subject :)
17:24:25 <maxamillion> (sorry, I'm in a meeting at $dayjob with my laptop ... trying to juggle both)
17:24:33 <tflink> #link https://www.redhat.com/archives/anaconda-devel-list/2012-January/msg00207.html
17:24:34 <adamw> maxamillion: yeah
17:24:41 <adamw> so for alpha, i'd say this is fairly clearly not a blocker
17:24:49 <jskladan> imho not an alpha blocker
17:24:49 <adamw> upgrades are beta stuff - even graphical upgrades
17:24:53 <jskladan> aaa ninja'd
17:24:57 <adamw> =)
17:24:57 <maxamillion> adamw: awesome, thanks
17:25:01 <maxamillion> nack
17:25:01 <adamw> we could bump it to a beta proposal
17:25:15 <tflink> maxamillion: there is no proposal yet :)
17:25:21 * maxamillion is confused
17:25:23 <maxamillion> ok
17:25:33 <adamw> maxamillion: it's kinda silly
17:25:37 <maxamillion> I thought the proposal was to make that bug a blocker
17:25:44 <adamw> maxamillion: we usually discuss it for a bit
17:25:45 <maxamillion> or is that not inferred?
17:25:47 <tflink> before the proposal, we're voting +1/-1 blocker/nth
17:25:48 <maxamillion> ah, ok
17:25:53 <adamw> you can vote +1 or -1 during that time
17:25:56 <maxamillion> -1
17:26:12 <maxamillion> I think at alpha phase, upgrades are a NTH
17:26:18 <adamw> then whoever's running the meeting will propose a complete action - make it a blocker or not a blocker, with justification - and we vote ack/nack/patch on that
17:26:20 <tflink> agreed that it isn't a blocker for alpha but it might be good to poke for movement before beta
17:26:34 <adamw> it's important that everyone's okay with the precise text of the action because it winds up in the bug report and the meeting log.
17:26:39 <adamw> yay for bureaucracy!
17:26:51 <tflink> I'd rather avoid the text-mode limbo that we had for F16
17:26:59 <adamw> yeah, we should definitely sort it out for beta
17:27:06 <adamw> either fix it or block text mode upgrades
17:27:09 <maxamillion> adamw: rgr
17:27:11 <adamw> that's what we need anaconda team to decide
17:27:27 * tflink is wondering about nth for alpha
17:27:51 <tflink> or just push it to beta and get out the pointy stick
17:28:20 <tflink> thoughts?
17:28:22 <adamw> nth for alpha...hum, prolly okay with me
17:29:05 * tflink is ok with either as long as we figure it out for beta
17:29:25 <adamw> yeah, i'm kinda either way on nth for alpha, but definitely beta blocker.
17:30:01 <pschindl> +1 for beta blocker
17:30:23 <maxamillion> +1 for beta blocker
17:30:27 * jskladan is not sure, what is the impact of nth, so stays silent
17:30:36 <tflink> pschindl, maxamillion : any thoughts on alpha nth?
17:30:45 <adamw> 'nth' is nice-to-have
17:30:51 <maxamillion> yeah, I'd +1 it as an alpha nth
17:30:56 <adamw> what it means is that a fix for it can be pulled through the freeze
17:30:58 <tflink> which is a horribly named type, I think
17:31:05 <maxamillion> tflink: probably so, yes :)
17:31:18 <pschindl> I don't think it's nice to have. I rather see it as nice to do not have :)
17:31:24 <adamw> packages can't be pulled through the freeze without an associated nth bug
17:31:37 <adamw> see https://fedoraproject.org/wiki/QA:SOP_nth_bug_process
17:31:52 * maxamillion checks the link
17:32:10 <tflink> nth or blocker bug
17:32:22 <tflink> the difference being that we hold release for blockers but not for nth
17:32:41 <adamw> anyway
17:32:45 <adamw> let's just make it a beta blocker and move on
17:32:46 <tflink> so it sounds like were vaguely for nth on alpha
17:32:47 <adamw> this is taking too long
17:32:52 <tflink> that sounds better
17:33:18 <pschindl> it should be blocker. We have beta criterion for this
17:33:27 <maxamillion> nth for alpha, blocker for beta .... is my opinion
17:33:35 <tflink> proposed #agreed - 742207 - AcceptedBlocker (beta) - The installer must be able to successfully complete an upgrade installation from a clean, fully updated default installation (from any official install medium) of the previous stable Fedora release, either via preupgrade or by booting to the installer manually. The upgraded system must meet all release criteria
17:33:48 <tflink> ack/nak/patch?
17:33:49 <pschindl> ack
17:33:54 <jskladan> ack
17:34:04 <maxamillion> ack
17:34:08 <adamw> ack
17:34:19 <tflink> proposed #agreed - 742207 - RejectedBlocker, RejectedNTH (alpha), AcceptedBlocker (beta) - The installer must be able to successfully complete an upgrade installation from a clean, fully updated default installation (from any official install medium) of the previous stable Fedora release, either via preupgrade or by booting to the installer manually. The upgraded system must meet all release criteria
17:34:25 <tflink> just being more specific
17:34:30 <tflink> #agreed - 742207 - RejectedBlocker, RejectedNTH (alpha), AcceptedBlocker (beta) - The installer must be able to successfully complete an upgrade installation from a clean, fully updated default installation (from any official install medium) of the previous stable Fedora release, either via preupgrade or by booting to the installer manually. The upgraded system must meet all release criteria
17:34:42 <tflink> #topic (784677) image installs erroneously change system hostname setting
17:34:45 <tflink> #link http://bugzilla.redhat.com/show_bug.cgi?id=784677
17:34:46 <buggbot> Bug 784677: unspecified, unspecified, ---, anaconda-maint-list, NEW, image installs erroneously change system hostname setting
17:34:48 <tflink> #info Proposed Blocker, NEW
17:35:43 <tflink> is this a sw raid issue?
17:35:44 * jskladan can not find alpha or beta criterion which would make this a blocker
17:36:23 <tflink> it sounds like RAID labels won't be created correctly if the hostname isn't set in the right place
17:36:24 <adamw> "Adding to F17Alpha since this should be a fairly quick fix and needs to make F17." - that's not what the blocker process is for.
17:37:09 <tflink> this might be beta blocker material but I'm -1 blocker, -1 nth on this for alpha
17:37:16 <adamw> anyone know what dlehman means by 'disk image install'?
17:37:19 <adamw> i'm a bit confused.
17:37:32 <tflink> adamw: I think it's an issue with sw raid installs
17:37:49 <tflink> anaconda isn't setting the hostname correctly and that's messing with installs that create RAID volumes
17:37:52 <adamw> i don't think it is.
17:38:00 <adamw> the reproduction steps don't mention raid.
17:38:12 <adamw> the change that *causes* the bug was related to raid, but it doesn't mean the bug only happens on raid installs.
17:38:18 <tflink> yeah, I misread the bug
17:38:20 <adamw> i'm not 100% clear though, as i'm not sure what 'disk image install' means.
17:38:34 <jskladan> it seems like if you'd be doing some installation from running system to other disk
17:38:39 <jskladan> (maybe some cloning?)
17:38:54 <jskladan> and you set the hostname for the _new_ system in anaconda UI
17:39:13 <jskladan> which then sets it on the 'host' system from which you run the installation
17:39:17 <tflink> unless I'm missing something, this sounds like not blocker material
17:39:26 <jskladan> tflink: +1 not a blocker
17:39:37 <pschindl> +1 not a blocker
17:39:41 <adamw> well, i know i'm missing something, so i'd like to know what the 'something' is before voting :) but if no-one can explain, i'd say we punt and ask for clarification
17:40:58 <jskladan> but I guess we can agree on "not an alpha blocker" and move on
17:41:01 <jskladan> or not? :)
17:41:06 * tflink plays elevator music while we wait for a response
17:41:21 <jskladan> tflink: muzak ftw!
17:41:23 <adamw> dlehman says " installing to a file that contains what could be used for, eg: a virt disk"
17:41:34 <adamw> i must be particularly dense today, because i'm still not entirely sure what the hell that means.
17:41:40 <tflink> I still don't understand the impact of this
17:41:54 <tflink> adamw: then there are at least 2 dense people here :)
17:41:56 <jskladan> adamw: IMHO that's what I've been talking about: you have a running system
17:42:04 <jskladan> from which you perform some installation
17:42:05 <maxamillion> add me to the list of dense
17:42:12 <jskladan> to a file
17:42:14 <jskladan> or whatever
17:42:23 <jskladan> and the anaconda has an "hostname" text box
17:42:38 <tflink> which sounds like not-blocker-material and non-standard-workflow to me
17:42:39 <jskladan> which you file in order to set the hostname for the newly installed system
17:42:52 <adamw> yeah, i think you're right
17:43:08 <tflink> it sounds like an issue for an anaconda dev environment, not actual usage
17:43:15 <jskladan> yup
17:43:41 <jskladan> imho not a blocker not a nth
17:44:20 <adamw> <bcl> adamw: that's one of the methods that livemedia-creator uses.
17:44:21 <adamw> <dlehman> you have to have anaconda installed on the same system it's meant to install, then you run something like 'anaconda --image=/path/to/disk/image/file'
17:44:33 <maxamillion> oh
17:44:36 <maxamillion> well that's interesting
17:45:04 <tflink> proposed #agreed - 784677 - RejectedBlocker RejectedNTH - Doesn't hit any of the alpha release criteria
17:45:10 <adamw> ack
17:45:12 <jskladan> ack
17:45:13 <maxamillion> ack
17:45:21 <pschindl> ack
17:45:22 <tflink> #agreed - 784677 - RejectedBlocker RejectedNTH - Doesn't hit any of the alpha release criteria
17:45:35 <tflink> #topic (750376) nss 3.13 breaks sssd TLS
17:45:35 <tflink> #link http://bugzilla.redhat.com/show_bug.cgi?id=750376
17:45:35 <tflink> #info Proposed Blocker, MODIFIED
17:45:36 <buggbot> Bug 750376: urgent, unspecified, ---, emaldona, MODIFIED, nss 3.13 breaks sssd TLS
17:46:15 * jskladan does not know a bit about this, back to the muzak...
17:47:43 <tflink> it sounds like there might have been some yum breakage at some point
17:48:28 <adamw> so this looks to be fixed in current rawhide
17:48:51 * tflink still isn't 100% sure of the impact
17:48:58 <tflink> broken ssl, ssh?
17:49:50 <adamw> so this was proposed by sgallagh back last nov
17:49:55 <adamw> yeah i'm trying to follow it, seems like a complex bug
17:49:55 <maxamillion> I think this has more to do with TLS+LDAP authentication for accounts .... but I'm still only about 2/3 of the way through reading the bug report
17:49:59 <adamw> sssd is remote auth stuff
17:50:09 <adamw> but i want to be sure there isn't actually some worse breakage buried in here
17:51:52 <adamw> i'm leaning towards ask for clarification and punt, here
17:52:01 <adamw> don't want to miss an important bug in a complex report like this
17:52:09 <tflink> yep, sounds like a plan to me
17:53:00 <tflink> proposed #agreed - 750376 - We need more information on the impact of this bug and whether or not it has been fixed in rawhide before making a decision
17:53:01 <maxamillion> if I'm not mistaken, this bug looks like its close to resolution ... comment #65 looks positive
17:53:08 <maxamillion> but yeah, I think more information is likely a solid plan
17:53:12 <maxamillion> ack
17:53:24 <adamw> ack
17:53:36 <tflink> #agreed - 750376 - We need more information on the impact of this bug and whether or not it has been fixed in rawhide before making a decision
17:53:47 <tflink> #topic (725219) anaconda should run in clone not span mode
17:53:48 <tflink> #link http://bugzilla.redhat.com/show_bug.cgi?id=725219
17:53:48 <tflink> #info Proposed Blocker, NEW
17:53:49 <buggbot> Bug 725219: low, unspecified, ---, ajax, NEW, anaconda should run in clone not span mode
17:54:03 <jskladan> yay, my 'favourite one'
17:54:08 <tflink> adamw: is the whiteboard your handywork?
17:54:23 <adamw> yeah
17:54:30 <adamw> but i also re-proposed this
17:54:49 <adamw> because it got kinda worse in f16
17:55:10 <jskladan> you mean the "guess the invisible button" game? :)
17:55:19 <adamw> yup
17:55:30 <adamw> comment #48
17:55:44 <adamw> the workaround is 'unplug a monitor', which kind of sucks.
17:55:46 <maxamillion> yeah, I just read that one ... sounds kinda sketchy
17:56:20 <maxamillion> I think the workaround is tolerable if extremely necessary, but if the patch wouldn't be an act of pulling teeth I certainly think this would be nice to have
17:56:27 <tflink> not sure we have a criteria for this, though
17:56:32 <maxamillion> I'm conflicted on it
17:57:03 <jskladan> imho there is not a criterion for this, even though this is extremely unpleasan bug
17:57:10 <maxamillion> yeah
17:57:12 <maxamillion> that's a fair point
17:57:23 <adamw> yeah, there isn't really a criterion that fits it great, we'd have to stretch one
17:57:35 * maxamillion gets out the yoga mat
17:57:37 <tflink> we could attempt to use "The installer must be able to complete an installation using the text, graphical and VNC installation interfaces"
17:57:39 <adamw> it'd just be the 'you have to be able to install' criterion with a situational qualification
17:57:44 <adamw> yeah, that'd be the one
17:58:04 <adamw> but i'm okay with rejecting it, really
17:58:22 <pschindl> I think it could be nth
17:58:23 <jskladan> +1 on rejecting it as blocker
17:58:30 <maxamillion> +1 to reject as blocker
17:58:35 <maxamillion> +1 for NTH
17:58:57 <jskladan> +1 on nth, even though I think that anaconda guys won't spend much time on it
17:58:59 <tflink> +/- 0 on blocker
17:59:18 <tflink> I'm not even sure this qualifies as NTH
17:59:27 <tflink> why would we take a fix for this past freeze?
17:59:55 <jskladan> because installing without next button sux :D
18:00:23 <adamw> yeah, just because it's a really visible and annoying bug, really.
18:00:35 <tflink> I'm not arguing on whether or not it sucks but why does that justify taking a fix past freeze?
18:00:53 <adamw> we've done it on that basis before.
18:00:54 <rbergeron> http://rbergero.fedorapeople.org/schedules/f-17/f-17-quality-tasks.html <-- me casually drops that in here for when people get a chance
18:01:21 <tflink> which is why I hate the NTH name
18:01:32 <tflink> but it sounds like the consensus is +1 NTH?
18:01:38 <adamw> rbergeron: the
18:01:59 <adamw> rbergeron: the 'pre-beta acceptance test plan' and 'pre-rc acceptance test plan' shouldn't exist
18:02:22 <adamw> rbergeron: other than that looks good, thanks!
18:02:27 <tflink> proposed #agreed 725219 - AcceptedNTH - There aren't any specific criteria for this bug but it is rather visable and interferes with installations
18:02:28 <adamw> tflink: yeah
18:02:32 <adamw> ack
18:02:33 <tflink> ack/nak/patch?
18:02:34 <pschindl> ack
18:02:35 <rbergeron> oh, you're right
18:02:36 <jskladan> tflink: ack
18:02:50 <tflink> #agreed 725219 - AcceptedNTH - There aren't any specific criteria for this bug but it is rather visable and interferes with installations
18:02:57 <adamw> rbergeron: we replaced those rats runs with tcs, we didn't just bump everything up
18:03:14 <tflink> OK, that's it for the proposed blockers
18:03:19 <tflink> on to the one proposed NTH
18:03:22 <tflink> #topic (741549) Login failure due to bad ~/.local/share/icc selinux file contexts
18:03:25 <tflink> #link http://bugzilla.redhat.com/show_bug.cgi?id=741549
18:03:27 <buggbot> Bug 741549: unspecified, unspecified, ---, bnocera, NEW, Login failure due to bad ~/.local/share/icc selinux file contexts
18:03:28 <tflink> #info Proposed NTH, NEW
18:04:26 <adamw> ah, looks like this is basically fixed now. though i'll want to re-test an f15->f17 upgrade just to be sure.
18:05:27 <tflink> I'm -1 NTH on this
18:05:36 <tflink> if it's still an issue, it sounds like a blocker
18:05:58 <tflink> nvm, I'm reading too fast again
18:06:12 <jskladan> partially of-topic - is there a criterion for upgrading from F-X to F-(X+2)? /me can't find it
18:06:17 <adamw> it's a bit too specific to be a blocker
18:06:33 <adamw> jskladan: no, there isn't; a two-release upgrade is specifically *not* blocking
18:06:37 * maxamillion has to run for about 15 minutes
18:06:37 <tflink> yeah, I spoke too soon
18:06:45 <adamw> though actually, if you upgraded f15->f16 then f16->f17, you'd probably still hit it. if it wasn't fixed.
18:06:52 <tflink> maxamillion: hopefully we'll be done in 15 minutes :)
18:06:55 <jskladan> adamw: ah, seems legit :)
18:07:07 <adamw> but it's still not really blocking, it depends on having done something specific prior to the upgrade.
18:07:18 <jskladan> +1 ^^
18:07:29 <tflink> since it's an upgrade issue, NTH beta?
18:08:41 <adamw> sure, whatever. if it's already been changed i'm less worried about it.
18:09:31 * jskladan is rather indifferent to this
18:09:53 <adamw> tell you what, for now i withdraw the proposal
18:10:00 <adamw> i'll re-propose it if it seems to become urgent again'
18:10:01 <tflink> proposed #agreed - 741549 - Upgrades are beta issues, RejectedNTH for alpha, re-propose as Beta NTH
18:10:30 <adamw> nack
18:10:34 <adamw> i just un-proposed it
18:10:37 <adamw> so there's nothing to reject :)
18:10:54 <adamw> propose #agreed 741549 - adam un-proposed this, so no action required
18:11:08 <jskladan> ack ^^
18:11:15 <tflink> #agreed 741549 - adam un-proposed this, so no action required
18:11:31 <tflink> well, that's it for the blocker/nth bugs
18:11:36 <tflink> #topic open floor
18:11:48 <tflink> any other issues/bugs to bring up?
18:11:57 * tflink sets fuse for 5 minutes otherwise
18:11:59 * jskladan is hungry
18:12:12 <adamw> nope, burn that fuse
18:12:16 <tflink> jskladan: do you have a bz for that?
18:12:20 <adamw> we need to do rats #2, dgilmore is composing it today
18:12:25 <jskladan> i wish :D
18:12:51 <tflink> well, without a BZ, I can't make it a topic :-D
18:13:02 <jskladan> got it closed by the significant other as WONTFIX
18:13:40 <tflink> jskladan: not sure I've ever thought of handling things that way
18:14:14 <jskladan> :D
18:14:25 <jskladan> ok /me runs for the bus
18:14:27 <tflink> #info Next blocker bug review meeting - 2012-02-03 @ 17:00 UTC
18:14:41 * tflink will be sending out minutes shortly
18:15:19 <adamw> secretaryizing is all done
18:15:28 <maxamillion> annnnd I'm back
18:15:36 <maxamillion> annnnnd it appears I missed the end of the show
18:16:13 <tflink> maxamillion: not quite, there is still 1 minute left on the fuse
18:16:31 * maxamillion runs like hell
18:16:33 <maxamillion> >.>
18:16:46 * tflink realizes that he's holding the fuse
18:16:54 <maxamillion> :P
18:17:05 <tflink> boom!
18:17:13 <tflink> thanks for coming everyone!
18:17:16 <tflink> #endmeeting