17:00:14 <jlaska> #startmeeting F-15-Beta blocker review 17:00:14 <zodbot> Meeting started Fri Mar 11 17:00:14 2011 UTC. The chair is jlaska. Information about MeetBot at http://wiki.debian.org/MeetBot. 17:00:14 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic. 17:00:14 <jlaska> #meetingname f-15-beta-blocker-review 17:00:14 <zodbot> The meeting name has been set to 'f-15-beta-blocker-review' 17:00:16 <jlaska> #topic Roll call 17:00:29 * tflink is here 17:00:33 <jlaska> okay, it's blocker review time ... who is here to help us through the list? 17:00:55 * red_alert here, at least for the first half or so 17:00:57 <saccia> I'm here to watch the show 17:01:03 <jlaska> red_alert: okay 17:01:05 <jlaska> saccia: :) 17:01:17 <adamw> here 17:01:51 <jlaska> rbergeron noted she may not be able to join 17:02:00 <jlaska> anyone from rel-eng, dgilmore lurking? 17:02:31 <jlaska> will get started in 1 minute 17:02:42 * nirik is lurking around, ping if needed. 17:02:56 <jlaska> nirik: okay, thanks 17:03:44 <jlaska> alright, let's get movin 17:03:54 <jlaska> #topic Useful information 17:04:03 <jlaska> #info Our purpose is to review proposed beta 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:04:15 <jlaska> and some handy links to reference through the meeting ... 17:04:16 <jlaska> #link https://fedoraproject.org/wiki/QA:SOP_Blocker_Bug_Meeting 17:04:16 <jlaska> #link http://bit.ly/f15-beta-blocker-proposed 17:04:16 <jlaska> #link http://bit.ly/f15-beta-blocker-accepted 17:04:17 <jlaska> #link http://bit.ly/f15-beta-nth-proposed 17:04:30 <jlaska> I'm going to start with the first list ... the proposed beta blockers 17:04:40 <jlaska> any comments before we go? 17:04:48 <red_alert> list is huge :/ 17:05:00 <jlaska> well, I have a surprise for the next toipc 17:05:03 <jlaska> topic 17:05:15 <jlaska> #topic Proposal for MODIFIED anaconda bugs 17:05:35 <tflink> I assume that the alpha label on that list is in name only? 17:05:39 <jlaska> so rather than spend time reviewing all the proposed MODIFIED already fixed and bodhi'd anaconda bugs ... 17:05:53 <jlaska> #info Clumens and I reviewed the MODIFIED anaconda bugs that are already fixed and available for testing in anaconda-15.22-1 17:06:00 <jlaska> tflink: which list? 17:06:15 <tflink> any of the bitly links you sent out to the beta blockers 17:06:21 <tflink> the lists in bz say alpha 17:06:23 <jlaska> tflink: yup that's just noise 17:06:31 <tflink> k, just making sure 17:06:35 <jlaska> thanks 17:06:54 <jlaska> okay, so there are 17 (or so) MODIFIED *and* already fixed anaconda proposed beta blockers 17:06:58 <red_alert> can we get a TC for anaconda 15.22-1 then? 17:07:06 <jlaska> red_alert: that's coming next week ... *or* 17:07:14 <jlaska> you can try a boot.iso I just built ... 17:07:22 <jlaska> http://jlaska.fedorapeople.org/boot.iso 17:07:27 <jlaska> so we can test and find newbugs 17:07:32 <adamw> if the proposal is 'let's skip them' the answer is 'hell yes' 17:07:36 <jlaska> proposed #agreed accept all MODIFIED anaconda bugs fixed_in <= anaconda-15.22-1 17:07:39 <jlaska> :) 17:07:40 <jlaska> +++1 17:07:41 <red_alert> I have several livecd bugs to test...boot.iso is no good :) 17:07:52 <jlaska> red_alert: you'll need to create a live image 17:08:09 <tflink> works for me 17:08:11 <jlaska> red_alert: or we can supply anaconda karma to get anaconda-15.22-1 into the 'base' repo 17:08:26 <jlaska> red_alert: use a nightly live and install that anaconda update 17:08:27 <clumens> i couldn't agree more. 17:08:40 <jlaska> #agreed accept all MODIFIED anaconda bugs fixed_in <= anaconda-15.22-1 17:08:48 <jlaska> yay ... that just cut 2 hours off the meeting time 17:08:58 <clumens> outstanding. 17:09:18 <jlaska> alright, resuming with proposed beta blockers (sorted by component) 17:09:30 <jlaska> adamw: I'll make the bz updates to all those anaconda blockers post meeting 17:09:39 <adamw> cool 17:09:56 <adamw> let's find another 30 bugs to skip! 17:10:00 <jlaska> #action jlaska will add whiteboard:AcceptedBlocker to all MODIFIED fixed anaconda bugs 17:10:04 <jlaska> #topic https://bugzilla.redhat.com/show_bug.cgi?id=677080 17:10:06 <buggbot> Bug 677080: unspecified, unspecified, ---, tcallawa, NEW, 'F14' artwork is shown during F-15 installation 17:10:16 <jlaska> #info 'F14' artwork is shown during F-15 installation 17:10:42 <adamw> so, this should actually have been an alpha blocker, but we (qa) totally dropped the ball and managed not to add the artwork criteria to the f15 criteria pages...oops. 17:10:48 <jlaska> we (jlaska) 17:10:51 <adamw> makes it a no-brainer for beta. 17:10:52 <adamw> no, it was me! 17:11:00 <jlaska> no, share that sword! 17:11:02 <jlaska> :0 17:11:25 <red_alert> do we need to #agreed on who's fault it was? ;) 17:11:32 <jlaska> haha :) 17:11:51 <jlaska> +1 on beta blocker 17:11:54 <clumens> i blame everyone but myself. 17:12:02 <jlaska> clumens: good strategy 17:12:04 * adamw blames canada 17:12:20 <red_alert> +1 on beta blocker 17:12:47 <adamw> criterion is alpha "The default Fedora artwork must either refer to the current Fedora release under development (Fedora 15), or reference an interim release milestone (e.g. Alpha or Beta). If a release version number is used, it must match the current Fedora release under development. This includes artwork used in the installer, firstboot, graphical boot, graphical login and desktop background. ", btw 17:13:15 <jlaska> proposed #agreed 677080 - Valid Alpha release blocker, accepted as Beta blocker - whiteboard:AcceptedBlocker 17:13:18 <tflink> +1 on beta blocker 17:13:21 <adamw> ack 17:13:28 <tflink> ack 17:13:44 <jlaska> #agreed 677080 - Valid Alpha release blocker, accepted as Beta blocker - whiteboard:AcceptedBlocker 17:13:50 <jlaska> thanks I counted ack's and +1's 17:14:18 <jlaska> the design folks are already thinking about how to address the artwork for beta 17:14:28 <jlaska> so I'm not sure we need to poke more on this bug 17:14:31 <adamw> as long as they're on it i don't see we need to do anything here 17:14:35 <jlaska> right on 17:14:44 <jlaska> moving on ... 17:14:48 <jlaska> #topic https://bugzilla.redhat.com/show_bug.cgi?id=681062 17:14:50 <buggbot> Bug 681062: medium, unspecified, ---, rstrode, NEW, F15 Alpha RC2: broken quicklauncher present in default panel configuration 17:14:57 <jlaska> #info F15 Alpha RC2: broken quicklauncher present in default panel configuration 17:15:06 <adamw> jlaska: um, i think you missed one anaconda bug that's NEW not MODIFIED 17:15:17 <adamw> 678414 17:15:20 <adamw> should we do that after this? 17:15:22 <jlaska> adamw: I did thanks, yup 17:15:44 <jlaska> this bug is pretty cut'n'dry 17:15:52 <adamw> right, the good news is, i'm pretty sure it's fixed post-alpha 17:15:58 <jlaska> from adamw ... "No part of the default desktop's panel (or 17:15:58 <jlaska> equivalent) configuration should crash on boot of the installed system using 17:16:01 <jlaska> default installation choices" - that criterion is a little too tightly worded, 17:16:04 <jlaska> it should also cover default panel configuration items being obviously 17:16:07 <jlaska> non-functional. 17:16:24 <adamw> i need to check the test day image in fallback mode to be sure, but after i updated the test system, the broken launcher went away 17:16:33 <adamw> so i expect it'll be the same after install now as well 17:16:39 <jlaska> okay, that'll be good 17:16:43 <jlaska> one less issue to worry about 17:16:57 <jlaska> should we move this to MODIFIED? 17:17:17 <adamw> yeah, probably a good idea, i'll do that with a comment 17:17:27 <jlaska> proposed #agreed 681062 - AcceptedBlocker - impacts beta destkop criteria 17:17:31 <jlaska> adamw: thx 17:17:42 <jlaska> proposed #agreed 681062 - AcceptedBlocker - impacts beta desktop criteria 17:17:47 <jlaska> (with proper spelling) 17:17:56 <jlaska> I'm guessing ack from adamw 17:18:02 <adamw> yup 17:18:04 <jlaska> any other votes/concerns? 17:18:09 <tflink> ack. agree with adamw's assesment of the blocker criteria 17:18:32 <jlaska> okay, thanks 17:18:32 <red_alert> +1 17:18:33 <adamw> the acceptance test we use has this case as a 'fail', so we just need to line up the test and the criteria 17:18:54 <jlaska> adamw: are wiki changes needed for that 17:19:03 <jlaska> or this will get covered when we do TC1? 17:19:04 <adamw> yeah, it should come under my big Fix The Criteria topic 17:19:09 <jlaska> oh oh 17:19:10 <adamw> which i should be doing instead of falling off hills 17:19:19 <jlaska> #agreed 681062 - AcceptedBlocker - impacts beta desktop criteria 17:19:39 * tflink wonders how one falls off a hill 17:19:50 <jlaska> tflink: very carefully! :) 17:19:56 <jlaska> okay, jumping back to a few anaconda bugs 17:20:05 <jlaska> #topic https://bugzilla.redhat.com/show_bug.cgi?id=629311 17:20:06 <buggbot> Bug 629311: medium, low, ---, dlehman, ASSIGNED, install allows use of preexisting root filesystem without reformat 17:20:13 <jlaska> #info install allows use of preexisting root filesystem without reformat 17:20:40 <clumens> he's got a patch for that. i suggested it probably wasn't worth rocking the f15 bota for. 17:20:40 <jlaska> an oldie that dlehman recently fixed it seems 17:21:20 <jlaska> clumens: so you are -1 for F15Beta or F15Final? 17:21:24 <adamw> for me, this doesn't actually hit any beta criteria. 17:21:37 <jlaska> possibly final partitioning criteria 17:21:42 <adamw> you could argue it hits "The installer must be able to create and install to any workable partition layout using any file system offered in a default installer configuration, LVM, software, hardware or BIOS RAID, or combination of the above " for final. 17:21:52 <jlaska> right, but it's somewhat of an edge case imo 17:21:53 <adamw> i'd be +1 to nth for beta or final, though. 17:22:03 <jlaska> yeah, good call 17:22:15 <clumens> i am okay with that 17:22:19 <adamw> or just pushing the fix; we don't have to be super conservative, outside of freezes especially... 17:22:55 <adamw> clumens: i know we are/were the ones pushing for you to make more controlled changes to anaconda and it's awesome you're doing that, but sensible bug fixes are fine, especially when we're not right near a release point :) 17:23:15 <clumens> oh you've already agreed to a ton of sensible fixes - that's what that pile of MODIFIED ones was all about 17:23:21 <jlaska> proposed #agreed RejectedBlocker, AcceptedNTH - no specific beta criteria covered, possibly impacts Final partitioning criteria. 17:23:25 <adamw> right, but they don't have to be blockers to get fixed 17:23:50 <red_alert> jlaska: ack 17:23:56 <adamw> ack 17:23:59 <tflink> ack 17:24:14 <jlaska> clumens, sounds like you were okay with this too? 17:24:28 <clumens> yeah 17:24:38 <jlaska> #agreed RejectedBlocker, AcceptedNTH - no specific beta criteria covered, possibly impacts Final partitioning criteria. 17:24:58 <jlaska> so, I guess we'll wait until this goes into MODIFIED and ON_QA to reach out for testing 17:25:19 <jlaska> next up ... 17:25:24 <jlaska> #topic https://bugzilla.redhat.com/show_bug.cgi?id=676114 17:25:26 <buggbot> Bug 676114: medium, unspecified, ---, akozumpl, POST, iscsi --target kickstart option not actually used 17:25:33 <jlaska> #info iscsi --target kickstart option not actually used 17:25:59 <adamw> iSCSI is final 17:26:15 <jlaska> yeah 17:26:22 <adamw> so i'd say -1 F15Beta, +1 F15Blocker, +1 go ahead and fix it now if we have a fix :) 17:26:29 <jlaska> ack :) 17:26:41 <adamw> looks like it's waiting on a test from reporter. 17:27:15 <jlaska> proposed #agreed 676114 - iSCSI impacts Final release criteria - AcceptedBlocker for Final release. 17:27:29 <tflink> ack 17:27:31 <red_alert> ack 17:27:57 <adamw> ack 17:28:13 <adamw> do we have a bug secretary btw? 17:28:16 <jlaska> #agreed 676114 - iSCSI impacts Final release criteria - AcceptedBlocker for Final release. 17:28:25 <adamw> if not, i can do it 17:28:37 <jlaska> if no one takes it, I'll circle back post-meeting 17:28:50 <tflink> I can do it, assuming that I have the permissions 17:28:52 <jlaska> I'll definitely grab all those MODIFIED anaconda ones 17:29:06 <tflink> just going through after the meeting and changing the bugs to match what we decide, right? 17:29:15 <adamw> i usually do it as we're going along 17:29:16 <adamw> saves time 17:29:49 <jlaska> adamw: sure 17:29:59 <adamw> i'll do it, then! carry on... 17:30:12 <jlaska> :) 17:30:23 <jlaska> thank you 17:30:23 <tflink> I don't think that I have the permissions to modify those fields, anyways 17:30:32 <tflink> so its probably a good thing you're willing to do it :) 17:30:42 <jlaska> tflink: I don't believe special perms are required 17:30:51 <red_alert> you simply need to be logged in 17:30:55 <jlaska> #topic https://bugzilla.redhat.com/show_bug.cgi?id=678414 17:30:56 <buggbot> Bug 678414: high, high, ---, anaconda-maint-list, NEW, NFS ISO install fails during repo setup - umount.nfs4: /mnt/source: device is busy 17:31:02 <jlaska> #info NFS ISO install fails during repo setup - umount.nfs4: /mnt/source: device is busy 17:31:04 <tflink> I am logged in, but this is a discussion for another time, I think 17:31:27 <jlaska> This is waiting on feedback from someone named cranes maska 17:31:49 <jlaska> I'll ask him to test with a custom-built DVD image next week 17:32:43 <adamw> that durn cranes 17:32:49 <clumens> so lazy 17:32:59 <jlaska> agreed! 17:33:11 <jlaska> so ... impacts beta criteria - "The installer must be able to use the HTTP, FTP and NFS remote package source options " 17:33:12 <tflink> its still a beta blocker, though, right? 17:33:23 <adamw> yup, pretty clear cut 17:33:41 <jlaska> I'll ^w Cranes will test this whenever he gets a DVD.iso 17:33:46 <jlaska> TC1 or custom-built ... time permitting 17:34:17 <jlaska> #agreed 678414 - AcceptedBlocker for Beta, impacts NFS installation source beta criteria 17:34:43 <jlaska> okay, back to the non-installer bugs 17:34:47 <jlaska> #topic https://bugzilla.redhat.com/show_bug.cgi?id=682141 17:34:49 <buggbot> Bug 682141: unspecified, unspecified, ---, otaylor, NEW, gnome-shell failed to start when changing user language to Chinese(China) 17:35:01 <jlaska> #info gnome-shell failed to start when changing user language to Chinese(China) 17:35:55 <jlaska> another lang/keymap related issue 17:36:18 <jlaska> I'm curious if the result has changed since the big set of shell related updates this week 17:36:46 <jlaska> Hurry proposed this issue, stating "Proposed as F15Beta since it blocks all the users who need a simplified Chinese 17:36:49 <jlaska> environment of the system." 17:37:17 <jlaska> so as for # of impacted users, that's probably a good amount 17:37:37 <adamw> yeah. i still haven't proposed a revision of the criteria for lang-specific issues, but this certainly looks like one we should fix 17:37:45 <jlaska> Maybe "No part of the default desktop's panel (or equivalent) configuration should crash on boot of the installed system using default installation choices " 17:37:48 <adamw> basically this hits most people in mainland China 17:37:53 <jlaska> err, not panel really 17:37:55 <jlaska> yeah 17:38:15 <adamw> well it's just "In most cases, the installed system must boot to a functional graphical environment without user intervention" really 17:38:16 <tflink> does it fallback? 17:38:18 <adamw> (from alpha) 17:38:24 <jlaska> adamw: yeah, that's the one 17:38:41 <jlaska> tflink: fallback, as in resort to us keymap? 17:38:58 <jlaska> or english LANG I mean 17:39:01 <tflink> is it gnome entirely or just shell? 17:39:10 <jlaska> "gnome-shell failed to start unless changing the language back to English or 17:39:13 <jlaska> Chinese(Hong Kong) 17:39:15 <red_alert> I wonder if that affects simplified chinese only or other asian languages too 17:39:16 <jlaska> " 17:39:29 <red_alert> ok, that already answers my question :) 17:39:32 <jlaska> tflink: I suspect just the shell, but we could ask Hurry for feedback 17:39:46 <adamw> well, if the shell fails to start and doesn't fall back, you effectively have no desktop 17:39:56 <adamw> it's not clear whether it falls back, but i wouldn't want to count on it... 17:40:04 <jlaska> right, that at least gives us a potential workaround 17:40:36 <jlaska> proposed #agreed 682141 - AcceptedBlocker for Beta, likely impacts Alpha desktop criteria and impacts most people in mainland China 17:40:40 <jlaska> ack/nak/patch? 17:40:56 <jlaska> proposed #agreed 682141 - AcceptedBlocker for Beta, likely impacts Alpha desktop criteria and affects most people in mainland China 17:41:12 <adamw> provisional +1, we should check whether it falls back to panel, but even if it does...kinda icky. 17:41:22 <tflink> I think it depends on how much we want to split hairs and whether or not gnome falls back or just crashes and dies 17:41:35 <tflink> adamw said it better than I did, though 17:41:52 <jlaska> okay 17:41:52 <tflink> definately +1 if it doesn't fall back to panel 17:42:04 <jlaska> I have a feeling it doesn't gracefully fallback 17:42:10 <jlaska> but let's definitely ask for that info 17:42:23 <jlaska> shall we revist this next week 17:42:28 <adamw> sure 17:42:48 <adamw> or we can just agree on the above, ask the question, and adjust the status appropriately once we have an answer? 17:43:03 <jlaska> yeah, I'd rather just move fwd on this one 17:43:09 <jlaska> so ack to that 17:43:38 <jlaska> proposed #agreed 682141 - AcceptedBlocker for Beta, likely impacts Alpha desktop criteria and affects most people in mainland China, additional feedback needed from rhe 17:43:41 <tflink> ack: works for me 17:43:50 <adamw> patch 17:44:03 <jlaska> #chair adamw 17:44:03 <zodbot> Current chairs: adamw jlaska 17:44:27 <adamw> proposed #agreed 682141 - need to find out from rhe whether this results in unusable desktop or fallback mode; if the former this will be AcceptedBlocker and can be updated outside of meeting, if the latter, will revisit next week 17:44:39 <jlaska> much better 17:44:40 <jlaska> ack 17:45:05 <tflink> ack, much more clear this way 17:45:08 <adamw> #agreed 682141 - need to find out from rhe whether this results in unusable desktop or fallback mode; if the former this will be AcceptedBlocker and can be updated outside of meeting, if the latter, will revisit next week 17:45:25 <jlaska> if nothing else on this one, I'll move on 17:45:56 <jlaska> #topic https://bugzilla.redhat.com/show_bug.cgi?id=679814 17:45:57 <buggbot> Bug 679814: unspecified, unspecified, ---, bnocera, NEW, [abrt] gnome-user-share-2.30.2-4.fc15: do_pre_parse_initialization: Process /usr/libexec/gnome-user-share was killed by signal 6 (SIGABRT) 17:46:06 <jlaska> #info [abrt] gnome-user-share-2.30.2-4.fc15: do_pre_parse_initialization: Process /usr/libexec/gnome-user-share was killed by signal 6 (SIGABRT) 17:46:53 <jlaska> Definitely captured by final release criteria - "In most cases, there must be no SELinux 'AVC: denied' messages or abrt crash notifications on initial boot and subsequent login" 17:47:23 <adamw> right 17:47:39 <adamw> whether it hits "No part of the default desktop's panel (or equivalent) configuration should 17:47:39 <adamw> crash on boot of the installed system using default installation choices " ...i'm not sure 17:47:50 <jlaska> yeah, I debated that too 17:47:54 <adamw> i don't think this is part of the panel. the intent of that criterion is to do with the functionality of the panel, not just 'do you see any crashes' 17:48:13 <adamw> i.e. we consider it a bigger problem if bits of the panel are broken than just an ugly crash notification at login, which is why there's the split between beta and final there 17:48:17 <jlaska> right, I think with the panel crit. we didn't want to see dialogs saying "Applet failed to start [delete]" 17:48:36 <adamw> well it's just the idea that anything on the default panel is probably important, so nothing there should be broken 17:48:45 <tflink> it certainly doesn't seem to impact functionality much 17:48:46 <jlaska> yeah 17:48:50 <adamw> so for me this is final 17:48:55 <jlaska> ack for final 17:49:00 <tflink> +1 17:49:07 * adamw wonders if we need a Meta-Criteria page 17:49:14 <adamw> or i should just write the criteria better =) 17:49:20 <jlaska> no idea how this impacts desktop file sharing, but either way, Final 17:49:24 <tflink> as long as it doesn't get too verbose :) 17:50:04 <jlaska> proposed #agreed 679814 - AcceptedBlocker for Final release . covered by no AVC or ABRT notification on login final criteria 17:50:36 <adamw> ack 17:50:42 <tflink> ack 17:50:42 <adamw> do we want to make this Beta NTH too? 17:50:50 <adamw> i think it's something we should fix if we can for Beta. 17:50:57 <jlaska> sure, I'd like to see it fixed sooner 17:51:00 <tflink> if we have a fix, sure 17:51:03 <adamw> k 17:51:20 <tflink> but it doesn't seem to be that big of a deal other than annoyance and looks bad 17:51:30 <jlaska> #agreed 679814 - AcceptedBlocker for Final release, AcceptedNTH for Beta. Covered by no AVC or ABRT notification on login final criteria 17:51:42 <tflink> then again, I have a hard time keeping nouveau from freezing for more than 15 min so maybe my view is skewed 17:51:48 <adamw> hehe 17:51:51 <jlaska> :) 17:51:59 <jlaska> alright, next up ... 17:52:09 <jlaska> #topic https://bugzilla.redhat.com/show_bug.cgi?id=677953 17:52:11 <buggbot> Bug 677953: medium, unspecified, ---, kernel-maint, ASSIGNED, Unable to kickstart with ks.cfg file stored on hard drive 17:52:17 <jlaska> #info Unable to kickstart with ks.cfg file stored on hard drive 17:52:44 <jlaska> impacts Beta criteria - "The installer must be able to use all kickstart delivery methods " 17:52:58 <adamw> yup, looks straightforward. 17:53:01 <tflink> yep 17:53:02 * jlaska reading details of bug 17:54:11 <adamw> me too 17:54:25 <adamw> looks like tester is using an external USB hard drive and it's not being mounted... 17:54:36 <jlaska> yeah 17:54:45 * jlaska updated to give hongqing some <ctrl>z guidance 17:55:02 <adamw> so, if we were down to the wire on this, we might argue that the installer can use the hard disk kickstart delivery _method_, this is more a bug with a particular case of hard drive _discovery_ 17:55:23 <jlaska> yeah, possible 17:55:27 <adamw> i can see that happening if this were the last bug on the list...so is it truly a blocker? 17:55:42 <tflink> or that it wasn't discovered until too late 17:55:44 <jlaska> I'd still push for this, but I need to know more 17:56:01 <adamw> clumens: you have any take on this? 17:56:02 <jlaska> loading a kickstart from a USB drive seems like a common use case for ks=hd:device:/path 17:56:48 <clumens> adamw: nothing offhand 17:56:52 <tflink> I wonder if it matters whether or not its an actual spinning HD or just a usb stick 17:57:12 <adamw> tflink: they do get handled differently, but yeah, it'd be nice to test. 17:57:24 <jlaska> let's ask hongqing for some extra info on this 17:57:25 <tflink> the way I'm reading this, they're using a spinning hd 17:57:38 <jlaska> whether it still happens with the latest anaconda-15.22-1, and the type of storage he is using 17:57:46 <adamw> okay 17:57:50 <tflink> unless I'm way off, ext3 on a usb stick is rare 17:57:54 <tflink> but agreed on more info 17:57:58 <adamw> revisit next week with more details? 17:57:59 <jlaska> I can confirm there isn't a general problem with ks=hd: ... so perhaps specific with the device type 17:58:09 <jlaska> ack to revisit next week 17:58:21 <tflink> sounds like a plan; ack 17:58:21 <adamw> okay, i'll update the bug with some questions 17:58:28 <jlaska> thanks 17:59:09 <jlaska> proposed #agreed 677953 - Need more information from hongqing on whether the issue remains with anaconda-15.22-1, and the type of storage used. Will revisit this bug next week. 18:00:19 <jlaska> I think we have the ack's needed on this already based on previous discussion 18:00:22 <tflink> were there any other questions on that 18:00:22 <jlaska> moving forward .. 18:00:28 <jlaska> #agreed 677953 - Need more information from hongqing on whether the issue remains with anaconda-15.22-1, and the type of storage used. Will revisit this bug next week. 18:00:37 <jlaska> if there are ... we can come back ... 18:00:40 <jlaska> #topic https://bugzilla.redhat.com/show_bug.cgi?id=678402 18:00:41 <buggbot> Bug 678402: high, unspecified, ---, mclasen, NEW, F15 livemedia are checking for updates 18:00:42 <tflink> very true 18:00:51 <jlaska> #info F15 livemedia are checking for updates 18:01:09 <jlaska> seems cut'n'dry here too ... 18:01:13 <jlaska> Beta criteria - "The desktop default update manager must not periodically check for updates when the system is booted live, but must periodically check for updates when running on an installed system " 18:01:31 <tflink> is it still doing that? I don't remember hitting that yesterday 18:01:33 <jlaska> sounds like we are just waiting for a new update of gsettings, so the live kickstart can be updated 18:01:49 <jlaska> tflink: ooh, good point, I don't know 18:02:17 <tflink> last update was almost a month ago 18:02:33 <tflink> to the bug, I mean 18:02:48 * jlaska asks mclasen 18:03:15 <adamw> i'm pretty sure it's still happening, but lemme check spin-kickstarts 18:03:55 <adamw> oh wait 18:04:01 <adamw> commit fae7f280dfbd346627b2882bcb3d5a01de406b29 18:04:01 <adamw> Author: Matthias Clasen <mclasen@redhat.com> 18:04:01 <adamw> Date: Tue Mar 1 11:04:34 2011 -0500 18:04:06 <adamw> gnome-packagekit is no longer using GConf, so tweaking GConf keys 18:04:06 <adamw> has little effect. Instead disable the gnome-settings-daemon updates 18:04:06 <adamw> plugin. 18:04:13 <adamw> so it looks like mclasen pushed a fix for this 18:04:30 <jlaska> cool ... move to MODIFIED and confirm with testing? 18:04:40 <adamw> i think so 18:04:47 <tflink> I assume that disable is for live media only, no? 18:04:51 <adamw> so, +1 blocker, set to modified, think it's fixed 18:04:56 <adamw> tflink: yes, that's a spin-kickstarts commit 18:05:10 <tflink> k, making sure 18:05:51 <jlaska> #agreed 678402 - AcceptedBlocker for Beta, seems to be fixed in spin-kickstarts, move to MODIFIED and verify fix 18:05:59 <tflink> ack 18:06:32 <adamw> ack 18:06:40 <jlaska> and ack from me too 18:06:48 <jlaska> if no nak's, I'll move on in a moment .. 18:06:59 <jlaska> #topic https://bugzilla.redhat.com/show_bug.cgi?id=683179 18:07:00 <buggbot> Bug 683179: medium, unspecified, ---, davidz, NEW, desktop- backgrounds package no longer sets the default Fedora background, due to changes in Gnome 18:07:15 <jlaska> #info desktop- backgrounds package no longer sets the default Fedora background, due to changes in Gnome 18:07:41 <jlaska> oh, so this is related to the earlier bug about incorrect desktop artowrk 18:07:44 <jlaska> artwork 18:07:58 <jlaska> apparently, there isn't support yet for distro-specific artwork on gnome3 18:08:12 <tflink> I thought that the debate over gnome vs fedora default wallpaper wasn't settled yet 18:08:15 <tflink> did I miss something? 18:08:16 <jlaska> I believe this bug is intended to track distro-overrides for this 18:08:48 <jlaska> tflink: I think this is slightly different from that 18:09:04 <tflink> jlaska: also true 18:09:09 <jlaska> related, but slightly different perhaps 18:09:32 <tflink> this isn't just about whether to change artwork but updating the method to do so 18:09:39 <jlaska> this bug tracks the ability for Fedora to actually have a background that differs from the default upstream selection 18:09:44 <adamw> right 18:09:46 <jlaska> tflink: yeah 18:10:00 <adamw> i think we were only ever going to take the upstream background on the live spin, too...not on media installs? or smth like that 18:10:10 <adamw> overall, for now i'd say +1 blocker 18:10:31 <jlaska> agreed 18:10:52 <jlaska> I think this is slightly chicken and egg with the other blocker about setting beta artwork 18:11:03 <tflink> yeah, this seems to fall under the artwork part of alpha release criteria 18:11:53 <jlaska> if for some odd reason, this issue isn't needed in order to make the proposed artwork changes, we can adjust accordingly 18:12:06 * jlaska fiddling w/ agreed wording 18:12:23 <adamw> agreed 18:12:44 <tflink> +1 18:13:00 <jlaska> proposed #agreed 683179 - AcceptedBlocker for Beta, impacts ability for Fedora to assert distro-specific artwork (alpha criteria). Will revisit if Fedora artwork policy changes. 18:13:02 <adamw> propose: #agreed 638179 provisionally accepted as a blocker per Alpha artwork criterion; if this fix turns out not to be needed for our agreed artwork approach for Fedora 15, this stops being a blocker 18:13:14 <adamw> either is good for me :) 18:13:16 <jlaska> ack to adamw's 18:13:29 <tflink> ack to adamw's version 18:13:42 <jlaska> adamw, make it so number one! 18:14:31 <jlaska> #agreed 638179 provisionally accepted as a blocker per Alpha artwork criterion; if this fix turns out not to be needed for our agreed artwork approach for Fedora 15, this stops being a blocker 18:14:41 <jlaska> 5 more proposed blockers ... 18:14:46 <jlaska> #topic https://bugzilla.redhat.com/show_bug.cgi?id=677734 18:14:47 <buggbot> Bug 677734: unspecified, unspecified, ---, davidz, NEW, [abrt] notification-daemon-0.7.0-4.fc15: gtk_window_configure_event: Process /usr/libexec/notification-daemon was killed by signal 6 (SIGABRT) 18:14:52 <jlaska> #info [abrt] notification-daemon-0.7.0-4.fc15: gtk_window_configure_event: Process /usr/libexec/notification-daemon was killed by signal 6 (SIGABRT) 18:15:53 <jlaska> I think this hits Final criteria - "In most cases, there must be no SELinux 'AVC: denied' messages or abrt crash notifications on initial boot and subsequent login" 18:16:03 <jlaska> and plenty of dups/cc on this one 18:16:25 <adamw> although all quite old 18:16:37 <jlaska> yeah, will want to retest with the current round of shell update 18:16:39 <jlaska> ? 18:16:40 <jlaska> updates 18:16:53 <adamw> there's no CCs since 02-25 which leads me to suspect this may be fixed 18:17:00 <jlaska> what are we at now? 18:17:01 * jlaska check 18:17:18 <jlaska> notification-daemon-0.7.1-1.fc15 18:17:33 <jlaska> Let's go big or go home ... 18:17:48 <jlaska> I propose CLOSED ERRATA with fixed_in=notification-daemon-0.7.1-1.fc15 18:18:02 <jlaska> and AcceptedBlocker for Final based on criteria above 18:18:12 <tflink> pushed to stable 2011-03-03 18:18:22 <tflink> so its been in there a little while 18:18:24 <jlaska> and we'll reopen certainly if problems come in again 18:18:48 <tflink> sounds good 18:18:52 <adamw> i guess ack 18:18:59 <jlaska> adamw: worries? 18:20:32 <jlaska> proposed #agreed 677734 - AcceptedBlocker for Final release based on no AVC or ABRT on login criteria. Appears to be fixed in current notification-daemon package. Move to MODIFIED and request test feedback. 18:20:39 <jlaska> okay, less aggressivve above 18:21:00 <tflink> I like that better, I was going to wait for wording 18:21:16 <adamw> yeah, i think just closing it is a bit premature 18:21:22 <jlaska> sure 18:21:27 <adamw> we can set MODIFIED and ask for reporters to verify they aren't seeing it any more 18:21:34 <jlaska> yeah, probably a safer bet 18:21:44 * jlaska feeling trigger happy 18:21:53 <jlaska> #agreed 677734 - AcceptedBlocker for Final release based on no AVC or ABRT on login criteria. Appears to be fixed in current notification-daemon package. Move to MODIFIED and request test feedback. 18:22:06 <jlaska> #topic https://bugzilla.redhat.com/show_bug.cgi?id=654762 18:22:08 <buggbot> Bug 654762: medium, low, ---, rstrode, NEW, plymouth does not start due to "Address already in use" error 18:22:13 <jlaska> #info plymouth does not start due to "Address already in use" error 18:22:15 <jlaska> oh this one 18:22:46 <jlaska> According to Lennart, this message is cosmetic and should be resolved 18:22:58 <jlaska> this issue isnt't tracking cases where /var/log/boot.log is empty 18:23:38 <jlaska> I definitely don't see the reported bz anymore 18:24:06 <jlaska> I don't think we have anything to accept this since it's not clear it actually breaks anything 18:24:27 <jlaska> unless any other ideas ... 18:24:55 <adamw> yeah, i think this bug is a red herring' 18:25:06 <adamw> afaik everyone got that message, some people assumed it was the cause of various other bugs but it never was 18:25:20 <jlaska> proposed #agreed 654762 - RejectedBlocker, message is cosmetic and should be fixed now. Move to MODIFIED and request test feedback. Any problems with /var/log/boot.log will be tracked elsewhere 18:25:42 <jlaska> I'm no longer seeing the message, so I'm fine with CLOSING the bug 18:25:51 <jlaska> ack/nak/patch? 18:26:13 <adamw> yup 18:26:17 <adamw> ack 18:26:18 <tflink> ack 18:26:28 <jlaska> good enough 18:26:34 <jlaska> #agreed 654762 - RejectedBlocker, message is cosmetic and should be fixed now. Move to MODIFIED and request test feedback. Any problems with /var/log/boot.log will be tracked elsewhere 18:26:42 <jlaska> 3 more ... 18:26:49 <jlaska> #topic https://bugzilla.redhat.com/show_bug.cgi?id=679503 18:26:51 <buggbot> Bug 679503: unspecified, unspecified, ---, rstrode, NEW, plymouth doesn't always transition to gdm 18:26:56 <jlaska> #info plymouth doesn't always transition to gdm 18:27:39 <jlaska> looks like adamw was reporting this also using the test day images 18:27:57 <adamw> right, i hit it 100% of the time with the image i was spinning for the test days 18:28:01 <jlaska> fun! 18:28:05 <adamw> i suspect current nightlies may have this bug too, but haven't checked 18:28:14 <jlaska> looks like lennart is aware of the issue 18:28:19 <jlaska> he DUPd a bug against this 18:29:31 <jlaska> I think this hits Alpha criteria "In most cases, the installed system must boot to a functional graphical environment without user intervention" 18:29:38 <jlaska> but I'm unclear on the "most cases" part of this bug 18:30:01 <jlaska> we want to leave this on the list for next week, and see if we have any other reports? 18:30:04 <adamw> yeah, i was only testing on one system 18:30:07 <adamw> so it may be a timing thing 18:30:21 <adamw> yeah it could probably cure for a while 18:30:50 <tflink> the only image I've tested recently was the one for yesterday's gnome3 test day 18:30:57 <tflink> i'd have to try it with a nightly 18:31:00 <jlaska> tflink: and that booted into gdm fine? 18:31:18 <tflink> most of the time 18:31:29 <tflink> about 1/4 would hang on gdm pre login screen 18:31:41 <tflink> but I filed a bug on that one 18:31:58 <tflink> adamw disabled plymouth on that image, no? 18:32:29 <adamw> yes 18:32:34 <adamw> i hacked around this bug for the test day 18:32:44 <adamw> the nightly won't have that hack 18:32:56 <jlaska> one moment ... phone ... 18:33:54 <jlaska> back 18:33:56 <satellit_afk> option control delete required to get gdm login on test day CD 18:34:04 <brunowolff> I have seen random hangs when unlocking encrypted partitions. 18:34:16 <brunowolff> That wouldn't effect live images though. 18:34:18 <jlaska> brunowolff: I have too, I think I have another bz out for that one 18:34:22 <adamw> satellit_afk: that's a different bug (whee) 18:34:29 <adamw> so, focus! 18:34:31 <jlaska> so ... thoughts for #topic bug? 18:34:35 <jlaska> :) 18:34:43 <adamw> i think we can wait and get some more feedback from this week's nightlies and stuff 18:34:49 <jlaska> sounds goodly 18:34:50 <adamw> maybe throw a mail to the list asking people to look out for it 18:34:52 <tflink> i think that we need more data, but it sounds like a blocker at the moment 18:35:05 <jlaska> yeah, if it holds, definitely a blocker 18:35:27 <brunowolff> gdm updates have been flakey this week. Is this with the latest update? 18:35:45 <jlaska> proposed #agreed 679503 - not enough information to review yet. Revisit next week and ask testers for help confirming this issue 18:35:53 <tflink> ack 18:36:18 <jlaska> brunowolff: when I filed it, it was against .91 18:36:21 <adamw> ack 18:36:22 <jlaska> (so a little older) 18:36:28 <jlaska> #agreed 679503 - not enough information to review yet. Revisit next week and ask testers for help confirming this issue 18:36:37 <adamw> yes, i tested with .91 and .93 and hit it with both 18:36:41 <jlaska> okay 18:36:42 <adamw> only disabling plymouth avoided it 18:36:44 <brunowolff> .93-2? 18:36:47 <adamw> yes 18:36:57 <jlaska> anything else on this one? 18:37:00 <adamw> no 18:37:07 <jlaska> #topic https://bugzilla.redhat.com/show_bug.cgi?id=646843 18:37:08 <buggbot> Bug 646843: medium, low, ---, rhughes, ASSIGNED, images/install.img will no longer exist in F-15 and newer 18:37:25 <jlaska> #info images/install.img will no longer exist in F-15 and newer 18:37:44 <jlaska> Upgrade are beta release items - "The installer must be able to successfully complete an upgrade installation from a clean, fully updated default installation of the previous stable Fedora release, either via preupgrade or by booting to the installer manually " 18:37:58 <jlaska> and this bug impacts preuprade support for F14->F15 18:38:11 <jlaska> (or the less "supported" F13->F15) 18:38:54 <jlaska> proposed #agreed 646843 - AcceptedBlocker for Beta due to beta upgrade criteria, will focus testing during upcoming preupgrade test day 18:39:12 <adamw> ack 18:39:15 <tflink> ack 18:40:09 <jlaska> #agreed 646843 - AcceptedBlocker for Beta due to beta upgrade criteria, will focus testing during upcoming preupgrade test day 18:40:23 <jlaska> #topic https://bugzilla.redhat.com/show_bug.cgi?id=678927 18:40:24 <buggbot> Bug 678927: unspecified, unspecified, ---, mgrepl, MODIFIED, SELinux denial prevents systemd-tty-ask from collecting password for unlocking encrypted /home partition 18:40:30 <jlaska> #info SELinux denial prevents systemd-tty-ask from collecting password for unlocking encrypted /home partition 18:41:05 <jlaska> Looks like we just need test feedback on this bugh 18:41:07 <jlaska> bug 18:41:17 <jlaska> (and of course, deciding if it's a beta blocker) 18:41:51 <jlaska> we discussed this as a possible Alpha blocker, and assuming my theory holds, I think this qualifies as a Final blocker because of "The installer must be able to create and install to any workable partition layout using any file system offered in a default installer configuration, LVM, software, hardware or BIOS RAID, or combination of the above " 18:41:58 <jlaska> (our partitioning catch-all) 18:42:17 <jlaska> mcepl: are you still seeing this issue? 18:42:43 <mcepl> which one? 18:42:45 * mcepl is looking 18:43:06 <mcepl> yes, it seemed to be gone, but it is back 18:43:19 <jlaska> alright, cool can you update the bz with your latest info? 18:43:25 <mcepl> when doing cold restart it is almost 100% 18:43:27 <jlaska> well, not cool, but thatnks for checking 18:43:28 <mcepl> ok 18:43:47 <adamw> was this the one where you need a non-default LVM scheme to hit it? 18:44:01 <jlaska> well, now that I think of it 18:44:10 <jlaska> I have a feeling this failure has slightly changed 18:44:29 <jlaska> because I'm now seeing the case the mcepl mentioned (cold start encrypted /home isn't mounted) 18:44:39 <mcepl> adamw: I don't remember what's wrong with my LVM layout ....??? 18:44:55 <mcepl> when I then reboot it works ok 18:44:59 <mcepl> I will update the bug 18:45:01 <jlaska> mcepl: my theory was whether this issue was triggered by encrypted LVM pv's or LVM lv's 18:45:19 <jlaska> mcepl: okay thanks, can you boot with the usual stuff .. plymouth.debug etc.. ? 18:45:22 <mcepl> no, I have encrypted LV ... is that weird? 18:45:40 <mcepl> I was feeding the stuff to mezcalero ... I will check whether I have it somewhere 18:46:07 <jlaska> mcepl: no, encrypted LV's are less weird 18:46:42 <jlaska> any ideas on this one? shall we revisit after Lennart and mcepl sync up? 18:47:02 <jlaska> and yes, this is our *last* proposed beta blocker 18:47:04 <tflink> yeah, I'd say make sure that the current issue is the one in the bug and revisit 18:47:59 <adamw> yeah, for me if this hits a default encrypted /home install it's Beta, otherwise Final 18:48:00 <tflink> since it may have disappeared and returned 18:48:23 <jlaska> proposed #agreed 678927 - bug appears to have been fixed, but may be failing again. mcepl will provide test feedback for lennart and we will revisit bug next week 18:48:31 <jlaska> adamw: I agree on that 18:48:37 <mcepl> adamw: the problem is that I don't do cold reboots that often, so I thought for some time it is gone. 18:48:54 <jlaska> ack/nak/patch? 18:49:14 <adamw> ack 18:49:19 <mcepl> and it probably shouldn't be MODIFIED, if that matters 18:49:19 <tflink> ack 18:49:44 <jlaska> mcepl: please do update the status based on your results 18:49:47 <tflink> not sure if this would be Beta, though but maybe I'm nitpicking 18:49:56 <tflink> we can cover that next week 18:49:59 <jlaska> right on 18:50:07 <jlaska> #agreed 678927 - bug appears to have been fixed, but may be failing again. mcepl will provide test feedback for lennart and we will revisit bug next week 18:50:21 <jlaska> okay, there were 2 bugs on the Accepted blocker list prior to the meeting 18:50:28 <jlaska> do we want to review those quickly for updates? 18:50:50 <adamw> sure 18:50:56 <jlaska> #topic https://bugzilla.redhat.com/show_bug.cgi?id=679486 18:50:58 <buggbot> Bug 679486: medium, low, ---, ajax, ASSIGNED, Unable to start graphical installer on RC1 KDE live image 18:51:23 <jlaska> I haven't retested this much since RC2 ... does anyone know if this is still an issue? 18:51:32 <jlaska> err, nm ... adamw posted a nice summary 18:51:36 <jlaska> comment#38 18:52:26 <jlaska> so this is a timing issue, and still a valid Beta blocker? 18:53:45 <jlaska> adamw: you're close to this one from the go/no_go meetings ... any ideas? 18:54:21 <adamw> sec 18:54:45 <adamw> nothing's really changed here. 18:55:05 <adamw> we've identified the issue quite precisely, really we just need the devs to decide upon and implement a fix. 18:55:18 <jlaska> okay 18:55:21 <jlaska> so no changes to make 18:55:36 <adamw> not really, maybe just a developer poke 18:55:54 <jlaska> #info no changes in this issue. Waiting for feedback from ajax for help moving forward 18:56:16 <jlaska> okay, the other bug I mentioned is already gone 18:56:36 <jlaska> so ... we have the option of going through proposed NTH bugs 18:56:56 <jlaska> do folks want to scan the NTH proposed list for anything worth reviewing? 18:57:09 <jlaska> #topic Open Discussion 18:57:24 <adamw> how long is it? :) 18:57:24 <jlaska> The proposed NTH Beta list is at - http://bit.ly/f15-beta-nth-proposed 18:57:38 <jlaska> 3 bugs 18:57:39 <jlaska> :) 18:57:55 <adamw> three? sure, let's do it. 18:58:00 <jlaska> alrighty ... 18:58:07 <jlaska> #topic https://bugzilla.redhat.com/show_bug.cgi?id=672527 18:58:08 <buggbot> Bug 672527: urgent, unspecified, ---, akozumpl, MODIFIED, Remote logging via virtio failed 18:58:31 <jlaska> This is something that hongqing has been working on ... it will be used in the virt install automation he is doing 18:58:49 <jlaska> so, by no means a blocker, but sure would be nice to get this in so his scripts can benefit from this 18:58:52 <clumens> damn, you guys must all be managers what with this kind of meeting fortitude. 18:59:00 * jlaska is about spent 18:59:31 <jlaska> so, clearly I'm all for NTH on this one 18:59:44 <jlaska> I'd prefer for the Beta 18:59:48 * tflink is scared about what would happen if more people were actively involved and arguing 18:59:55 <adamw> clumens: we've only been going two hours. this is a BABY meeting. 19:00:03 <jlaska> tflink: ssssh! don't stir folks up :) 19:00:23 <adamw> yeah, anything to do with diagnosis is important, +1 nth. 19:00:28 <jlaska> I'm 1000% sure that clumens is totally comfortable with NTH on this one too :) 19:00:39 <jlaska> (/me WAG'ing) 19:01:18 <clumens> it'd be nice 19:01:19 <tflink> +1 nth 19:01:30 <jlaska> #agreed 672527 - AcceptedNTH for Beta (or Final), improves virt-based installer diagnostics 19:01:37 <jlaska> okay, I think we have enoug hthere 19:01:39 <jlaska> there 19:01:59 <tflink> isn't that just waiting for feedback? 19:02:26 <jlaska> could be, it might actually be in anaconda-15.22-1 19:02:35 <adamw> next bug! 19:02:37 <jlaska> #topic https://bugzilla.redhat.com/show_bug.cgi?id=677609 19:02:39 <buggbot> Bug 677609: high, medium, ---, rvykydal, MODIFIED, IPv6 default gateway not honoured 19:03:02 <jlaska> Radek Vykydal asked for this ... and I have no problem with it at all 19:03:23 <tflink> also sounds like a fix is in anaconda 19:03:33 <jlaska> fixed in the next release 19:03:38 <jlaska> I don't believe it's built yet 19:03:41 <jlaska> so "fixed" 19:03:47 <tflink> 15.23-1 19:03:49 <jlaska> right 19:03:54 <tflink> ah, OK 19:04:17 <jlaska> but your point is valid ... not much to discuss here if it's already in the f15-branch 19:04:30 <tflink> still nth 19:04:32 <adamw> +1 nth 19:04:51 <jlaska> #agreed 677609 - AcceptedNTH, appears to be fixed and awaiting next anaconda-15.23-1 build 19:05:01 <mcepl> adamw: bugs updated ... I don't have those logs anymore, and if somebody else will reproduce it and if they are sent to Lennart, I would rather not do it. 19:05:06 <jlaska> last one 19:05:13 <jlaska> #topic https://bugzilla.redhat.com/show_bug.cgi?id=672135 19:05:14 <buggbot> Bug 672135: unspecified, unspecified, ---, jmccann, NEW, users with no "real name" in /etc/passwd show up as blank 19:05:16 <jlaska> I hate this bug 19:05:24 <jlaska> #info sers with no "real name" in /etc/passwd show up as blank 19:05:47 <jlaska> current proposal in the comments is making this a F15Blocker and Beta NTH 19:05:57 <jlaska> it's more of a polish issue for the Final than anything else 19:06:06 <tflink> huh, that would explain why I always have to enter in my username on one F15 system 19:06:08 <jlaska> and it would be nice to fiddle w/ gdm as little as possible after beta 19:06:21 <jlaska> tflink: yes, annoying huh! :D 19:06:27 <tflink> I'll have to try that 19:06:48 <jlaska> so my proposal on this was ... 19:07:35 <jlaska> proposed #agreed 672135 - AcceptedBlocker for Final release, AcceptedNTH for Beta. No specific criteria are impacted, but this is likely a visible polish issue 19:07:39 <adamw> i'd want at least a proposed criteria revision to accept this as a blocker 19:08:00 <adamw> it's not really a critical / urgent severity issue so we can't take it under the workaround 19:08:46 <jlaska> agreed on those points 19:09:23 <adamw> so, your revision proposal will hit the list soon? :P 19:09:24 <tflink> yeah, definitely not security but high visibility 19:09:46 <jlaska> adamw: you didn't se me sign up did you? :) 19:10:08 <adamw> you just did ;) 19:10:14 <jlaska> hey, wait! :) 19:10:24 * adamw quickly hides the box marked Cranes Maska Remote Control 19:10:38 <jlaska> we can add it to the growing box of criteria I haven't yet created, sure :) 19:11:05 <adamw> i'm definitely +1 nth 19:11:15 <jlaska> I have no idea how I'd phrase something like a polish issue ... and I'm certainly not going to have good ideas in this meeting! 19:11:17 <adamw> i'm not entirely convinced we can make a case for final blocker... 19:11:19 <jlaska> :) 19:11:28 <jlaska> more I think about it ... I tend to agree 19:11:33 <jlaska> we'd just bump it off that list too 19:11:35 <adamw> same old question - if this was the last bug, would we really slip a week for it? 19:11:37 <jlaska> let's NTH all the way 19:11:42 <jlaska> btw ... I hate that question :) 19:11:47 <adamw> we'd just say 'fill out the box, damnit' 19:11:57 <jlaska> right 19:12:07 <jlaska> so ... new proposal ... 19:12:29 <jlaska> proposed #agreed 672135 - AcceptedNTH for Final. No specific criteria are impacted, but this is likely a visible polish issue 19:12:40 <jlaska> and I'll bug Ray for thoughts on this one 19:12:41 <adamw> i'm fine with beta nth too 19:12:46 <jlaska> k 19:12:52 <jlaska> proposed #agreed 672135 - AcceptedNTH for Beta. No specific criteria are impacted, but this is likely a visible polish issue 19:12:58 <adamw> actually i was thinking we should probably mark anything we accept as nth for _all_ future release points, not just one 19:13:02 <adamw> but...can discuss that outside the meeting 19:13:09 <jlaska> okay 19:13:21 <jlaska> tflink: red_alert: brunowolff any ack/nak's on this one? 19:13:32 <tflink> ack 19:13:39 <tflink> I don't like it, but I agree on the blocker part 19:13:55 <jlaska> yeah, that captures my feelings as well 19:14:00 <jlaska> okay, thanks all ... I think that's enough for this bz 19:14:05 <jlaska> #agreed 672135 - AcceptedNTH for Beta. No specific criteria are impacted, but this is likely a visible polish issue. 19:14:10 <jlaska> #topic Open Discussion 19:14:18 <jlaska> I have one more topic I'd like to discuss ... 19:14:23 <jlaska> and that is that I'd like to #endmeeting *soon* 19:14:28 <jlaska> ... discuss 19:14:43 <adamw> ack! 19:14:52 <tflink> ack 19:14:56 <jlaska> hehe ... yeah, ack/nak/patch :) 19:14:57 <tflink> +11000 19:15:04 <jlaska> and I pity the fool that patches! 19:15:05 <adamw> +11000.01 19:15:18 <adamw> patch: I'd like to #endmeeting *now* 19:15:20 <tflink> adamw: you just had to .01 up me, didn't you? 19:15:24 <jlaska> adamw: Bam! 19:15:26 <jlaska> approved! 19:15:31 <adamw> #endmeeting