16:00:51 #startmeeting Fedora 14 Beta Blocker Review 16:00:51 Meeting started Fri Sep 3 16:00:51 2010 UTC. The chair is poelcat. Information about MeetBot at http://wiki.debian.org/MeetBot. 16:00:51 Useful Commands: #action #agreed #halp #info #idea #link #topic. 16:00:59 #chair jlaska adamw 16:00:59 Current chairs: adamw jlaska poelcat 16:01:16 who is hear for the F14 Beta Block Party? 16:01:21 s/hear/here 16:01:31 * jlaska 16:01:41 16:02:17 * skvidal just came by to make sure there was nothing he had to fix asap 16:02:28 skvidal: nope, just things you have to fix yesterday 16:02:39 lol 16:02:48 jlaska: did you announce in f-devel? 16:02:50 excellent 16:02:57 poelcat: I did 16:03:01 thanks 16:03:04 okay let's roll 16:03:16 #info attendees: jlaska adamw skvidal poelcat 16:03:39 #topic https://bugzilla.redhat.com/show_bug.cgi?id=621825 16:03:41 Bug 621825: medium, low, ---, tbzatek, NEW, [abrt] gnome-keyring-2.31.4-2.fc14: g_str_hash: Process /usr/bin/gnome-keyring-daemon was killed by signal 11 (SIGSEGV) 16:03:49 looks like it might already be fixed? 16:04:29 that's on f14blocker, not f14beta? 16:04:37 * nirik is busy otherwise, but lurking if needed. 16:04:50 * maxamillion will mostly be lurking but wanted to try to partake in this meeting as much as possible while still attempting to get $dayjob done 16:05:03 adamw: looks like i pulled up the wrong list :-/ 16:05:06 heh 16:05:41 poelcat: wishful thinking? 16:05:49 #topic https://bugzilla.redhat.com/show_bug.cgi?id=565323 16:05:50 Bug 565323: medium, low, ---, dwalsh, ASSIGNED, SELinux is preventing /usr/bin/python "write" access on sysctl.conf. 16:06:23 so, what's the justification for this one as a beta blocker? 16:06:25 i thought all AVCs were a blocker? 16:06:42 * poelcat could be wrong too :) 16:07:01 we have it for the final ... "In most cases, there must be no SELinux 'AVC: denied' messages or abrt crash notifications on initial boot and subsequent login" 16:07:12 okay, my bad 16:07:33 jlaska: indeed, note that only covers boot and login, though, not trying to add a network printer :) 16:07:49 adamw: right ... I gather that's the 'most cases' bit right? 16:08:03 i expect it'll get fixed pretty fast, selinux issues usually do, but i don't think it's a blocker under current criteria 16:08:18 adamw: so move to final blocker or target? 16:08:20 jlaska: the 'in most cases' is to let us wriggle out of the case where you have some bizarre bit of hardware that causes an avc most people won't see 16:08:27 adamw: agreed 16:08:30 +1 to F14Blocker 16:08:34 poelcat: if it shows up just by booting and logging in, it's f14blocker 16:08:43 if you have to do something else to trigger it, it's just target, i think 16:09:33 who wants to break the tie? jlaska vs. adamw 16:09:45 i guess i can 16:09:48 * adamw gets out light saber 16:10:14 I thought we were in agreement, F14Blocker, no? 16:10:22 or is adamw saying this is not a common use case? 16:10:46 i vote "blocker" I think adding a network printer is a common case 16:10:48 jlaska: well, just what i said above - if you have to do something besides just boot and log in to cause the avc, it's not a blocker under the criterion 16:11:02 did we stipulate only boot and login somewhere 16:11:14 I thought we also included starting apps in the menu's etc... 16:11:27 the main criterion was written right up there 16:11:40 you cited it 16:11:42 "In most cases, there must be no SELinux 'AVC: denied' messages or abrt crash notifications on initial boot and subsequent login" 16:11:59 heh, my own words to haunt me ... noooo oo o 16:12:13 it's basically a polish criterion, the point of it is that ugly 'stuff is broken!' notifications shouldn't pop up just by booting the system 16:12:20 so as written I agree that this doesn't meet the criteria 16:12:20 what about ammending that to say "... and common tasks using default package set" ? 16:12:34 you could argue it for "All applications listed under the Applications menu must withstand a basic functionality test and not crash after a few minutes of normal use" 16:12:41 that one's a bit fuzzy 16:13:12 adamw: we have some criteria in the final for those types of things 16:13:12 proposed #agreed https://bugzilla.redhat.com/show_bug.cgi?id=565323 move to f14target because it does not meet explicit blocker criteria 16:13:14 Bug 565323: medium, low, ---, dwalsh, ASSIGNED, SELinux is preventing /usr/bin/python "write" access on sysctl.conf. 16:13:22 ack/nak ? 16:13:32 poelcat: i'd want to be more explicit about 'common tasks', that's a very vague concept, but i can see where you're going 16:13:42 i'd ack that for now 16:13:52 jlaska: ? 16:14:03 anyone else 16:14:27 probably the easiest way to add it would be to add a 'no avc' stipulation to that criterion i just mentioned - "All applications listed under the Applications menu must withstand a basic functionality test and not crash after a few minutes of normal use" 16:14:37 poelcat: agreed 16:14:49 we have "# All applications listed under the Applications menu must start successfully " 16:14:59 but again it gets a bit hairy; in what circumstances? i'm not sure we'd want to guarantee you can never trigger an avc from any default installed gui app, that's pretty broad 16:15:00 perhaps adding '... and result in no AVC messages" 16:15:10 adamw: definitely 16:15:13 jlaska: just *running* the tools in question don't cause the denial, AIUI 16:15:19 so we'd have to define exactly what you can do with 'em 16:15:20 adamw: it shouldn't :) 16:15:24 erf, i think we're out of scope :) 16:15:26 yup 16:15:28 we need to move on 16:15:39 MC ... take us to the next bz! 16:15:39 so feel free to propose something more thought out as a criterion extension 16:15:43 but for now it doesn't qualify 16:15:52 #agreed https://bugzilla.redhat.com/show_bug.cgi?id=565323 move to f14target because it does not meet explicit blocker criteria 16:15:53 Bug 565323: medium, low, ---, dwalsh, ASSIGNED, SELinux is preventing /usr/bin/python "write" access on sysctl.conf. 16:16:04 * adamw will bug secretary 16:16:10 #topic https://bugzilla.redhat.com/show_bug.cgi?id=618504 16:16:11 Bug 618504: medium, low, ---, enrico.scholz, NEW, Cannot submit abrt bugs 16:17:01 no info since last time 16:17:23 yeah 16:17:24 discussed last week, pending test results to determine if this affects all abrt 16:17:28 what is an appropriate nagging method? 16:17:30 I think that's where we left it 16:17:36 did we assign someone to test this? was it me? :P 16:17:48 * adamw has submitted several bugs via abrt over the last week... 16:17:55 it seems to be working for me anyway 16:18:21 adamw: it was an open-ended test request iirc 16:18:32 i used it to reopen the selinxu bug we just discussed 16:18:38 so i WORKSFORME 16:18:52 close as such if working for > 1 person ? 16:19:04 * jlaska about to login to f14 desktop 16:19:16 bug can always be reopened 16:19:32 i think we should leave it open as discussion seems to indicate there's really a bug here 16:19:46 but we need more info on what the circumstances required to trigger the bug are, and it doesn't feel like a blocker to me at present\ 16:19:49 I don't mind leaving it open -- I'm just not sure it's a blocker 16:19:58 adamw: okay, next action(s)? 16:20:01 3rd strike will be next week then 16:20:11 NEEDMOREINFO 16:20:12 jlaska: great idea 16:20:21 i'd say leave it open to next week, re-evaluate based on any added info, if we don't get any, drop to target 16:20:33 +1 16:20:40 proposed #action https://bugzilla.redhat.com/show_bug.cgi?id=618504 no feedback from reporter, wait one more week and drop at next meeting if no feedback 16:20:41 Bug 618504: medium, low, ---, enrico.scholz, NEW, Cannot submit abrt bugs 16:20:46 ack/nak 16:20:57 ACK 16:20:58 ack 16:21:08 #action https://bugzilla.redhat.com/show_bug.cgi?id=618504 no feedback from reporter, wait one more week and drop at next meeting if no feedback 16:21:09 Bug 618504: medium, low, ---, enrico.scholz, NEW, Cannot submit abrt bugs 16:21:19 #topic https://bugzilla.redhat.com/show_bug.cgi?id=621027 16:21:20 Bug 621027: medium, low, ---, tcallawa, NEW, Graphical screen in anaconda shows F-13 16:21:43 that darned cranes...:) 16:22:19 cmaska: i believe the artwork criteria are on your todo? 16:22:28 adamw: you're updating comments/actions as we go, correct? 16:22:31 yes 16:22:32 it is ... I've had no feedback yet from the design-team 16:22:37 adamw: thank you! 16:22:48 so I'll make something up, repost for final review next week 16:22:50 mairin is all over my blog comments at the moment so she's got no excuse ;) 16:23:17 we could try and snag her, she's in -devel 16:23:18 I missed the design team meeting this week, but I wanted ot raise it for thoughts there 16:23:41 I've heard her talk about having that stuff on her plate, but I think she's for having a generic set of images for alpha/beta 16:23:58 * jlaska reached out to mizmo 16:24:11 i thought we were generally going for generic images for alpha but proposed final ones for beta so we get some feedback 16:24:24 just in case $WORLD hates our design 16:24:30 hey mo 16:24:30 mizmo_: hi there, thanks for joining :) 16:24:34 hiii :) 16:24:41 so ... we're talking about /topic bug 16:24:54 which has hilighted that we don't have good release criteria around fedora artwork 16:25:24 one proposal was to have generic release artwork available in Alpha, and the Final artwork available in Beta 16:25:58 so what we've discussed on the design team 16:26:02 bc of other issues 16:26:20 is that starting with f14 we're going to do more generic firstboot / syslinux / anaconda splashes 16:26:34 so they won't be tied to that releases theme, only the wallpaper will change drastically from release-to-release 16:26:53 (we might update the generic artwork once every 2 or 3 releases) 16:26:54 so 16:27:18 we'll have some generic 'Fedora alpha' 'Fedora beta' 'Fedora development' artwork that could be reused over and over 16:27:35 and plan to have the version number 'Fedora 14' artwork in during beta 16:27:47 if for some reason that isn't ready then the generic 'fedora beta' artwork could be used 16:27:50 how does that sound? 16:28:13 WORKSFORME 16:28:41 fine by me...bottom line, what would be the minimum acceptable at beta stage, the proposed final wallpaper should be in and other graphics should have either no version number or correct version number? 16:28:47 sounds like we'll have criteria around having milestone specific artwork (alpha, beta, final) ... and then the release-specific artwork in place by Final 16:29:05 ^^-->> note I list Final, not Beta. You mentioned having it in Beta would be ideal, but not required 16:29:55 adamw, yep 16:30:06 ok 16:30:14 so based on this working definition ... I believe that makes #topic bug a valid Beta blocker 16:30:14 jlaska, exactly. try to have it in by beta but not a huge issue if it doesn't make it 16:30:20 mizmo: okay, thanks 16:30:24 so under that proposal, the bug in question would indeed be a beta blocker, because we have artwork with a wrong version number 16:30:28 jlaska: snap :) 16:30:36 adamw: take it away my good man 16:31:23 * jsmith still thinks it would be ideal to have a script that adds the proper version number to a generic set of images 16:31:24 adamw: can you #action the next steps? 16:31:28 propose: #agreed tentatively accept #621027 as a beta blocker under mizmo's outlined proposal, write up a criterion for approval on list 16:31:43 ack 16:31:55 jsmith: i think the idea is to do that, but with completely unversioned images as a worst-case fallback if that goes wrong somehow... 16:31:55 I can take the criteria draft based on mizmo's feedback 16:31:59 ok cool 16:32:07 jsmith, ++ we can mark the # in inkscape and write python script to change it but 'alpha' 'beta' 'develoment' would have to be done by hand since they are longer than a # 16:32:23 #agreed tentatively accept #621027 as a beta blocker under mizmo's outlined plan 16:32:34 #action jlaska to draft release criteria based on mizmo's outline 16:32:34 #action jlaska - propose wiki artwork criteria additions based on mizmo feedback 16:32:37 heh 16:32:37 #undo 16:32:37 Removing item from minutes: 16:32:41 got it in stereo! 16:32:51 success! I'm no longer needed here :) 16:33:02 adamw: assign them to cranes, I'll be at the beach 16:33:33 #topic https://bugzilla.redhat.com/show_bug.cgi?id=623524 16:33:34 Bug 623524: medium, low, ---, anaconda-maint-list, NEW, Err during filesystem check after upgrading bootloader 16:33:36 * jsmith kicks sand on jlaska's beach towel 16:33:43 thanks mizmo 16:34:56 jsmith: hey man, blocking my sun! 16:35:19 we accepted this as a blocker last week, looks like it still needs info though, so i pinged hurry 16:35:35 jlaska: Are you calling me fat? 16:35:41 adamw: need me to follow-up with mingtao on this? 16:35:41 oh my 16:35:59 poelcat: Sorry --- just had to give jlaska a bad time 16:35:59 jsmith: oh no you didn't 16:36:32 coming up - is jsmith jlaska's baby daddy? find out after these messsages 16:36:42 LOL 16:37:04 adamw: that's it ... you get the 'final thought' for todays meeting again 16:37:06 * jsmith changes the channel 16:37:08 =) 16:37:18 okay ... continuing on ... 16:37:29 proposed #action https://bugzilla.redhat.com/show_bug.cgi?id=623524 jlaska to ping for more info 16:37:30 Bug 623524: medium, low, ---, anaconda-maint-list, NEW, Err during filesystem check after upgrading bootloader 16:37:32 ack/nak 16:37:32 jlaska: well i just posted the ping, so maybe give it a day 16:37:37 but yeah, that's good 16:37:38 adamw: okay 16:37:50 they're both fast responders ... so we should have info soon 16:38:00 #action https://bugzilla.redhat.com/show_bug.cgi?id=623524 conintuing to wait for more info 16:38:01 Bug 623524: medium, low, ---, anaconda-maint-list, NEW, Err during filesystem check after upgrading bootloader 16:38:12 #topic https://bugzilla.redhat.com/show_bug.cgi?id=624971 16:38:13 Bug 624971: medium, low, ---, anaconda-maint-list, NEW, Kernel argument with "UUID=" is not honored 16:38:29 "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 " 16:38:36 this was a blocker for the preupgrade test day :( 16:38:49 there is a new anaconda in the works, and pending testing that is supposed to resolve this issue 16:39:01 https://admin.fedoraproject.org/updates/anaconda-14.17-1.fc14 16:39:06 +1 blocker 16:39:52 guess we don't need much else here 16:39:54 no objections here 16:40:36 proposed #action https://bugzilla.redhat.com/show_bug.cgi?id=624971 accepted blocker hopefully resolved by new package 16:40:37 Bug 624971: medium, low, ---, anaconda-maint-list, NEW, Kernel argument with "UUID=" is not honored 16:40:39 ack/nak 16:40:40 ack 16:40:52 ack ack 16:40:55 #action https://bugzilla.redhat.com/show_bug.cgi?id=624971 accepted blocker hopefully resolved by new package 16:40:56 Bug 624971: medium, low, ---, anaconda-maint-list, NEW, Kernel argument with "UUID=" is not honored 16:41:08 #topic https://bugzilla.redhat.com/show_bug.cgi?id=627401 16:41:09 Bug 627401: medium, low, ---, clumens, ASSIGNED, please create systemd default.target symlink pointing to /lib/systemd/system/runlevelX.target instead of /etc/systemd/system/runlevelX.target 16:41:25 iirc, that's listed as fixed in the same anaconda bodhi update 16:41:43 see the comments, it looks like the fix was incorrect 16:41:55 indeed, doh! 16:42:16 sounds like the requirments changed on this 16:42:29 didn't change, it just wasn't entirely clear from the bug description 16:42:42 they thought that both the location of the symlink and its target needed to be changed to lib 16:42:50 in fact the symlink still needs to be in etc but its target moved to lib 16:43:15 it's a clear blocker, anyway - without a fix you get a system that won't boot right 16:43:37 what's boot right? ... does it never present a graphical login? 16:44:03 in the past if default.target wasn't there it'd just utterly fail to boot 16:44:19 lennart may have made it more fault-tolerant now so maybe it goes to single user mode or something, i'm not entirely sure 16:44:39 thanks for the info 16:44:53 but i'm pretty sure it would not get to graphical login or probably even a 'normal' console boot 16:44:54 either way, I agree ... not much folks will get out of the beta if this isn't correct 16:45:12 "When booting a system installed without a graphical environment, or when using a correct configuration setting to cause an installed system to boot in non-graphical mode, the system should provide a working login prompt without any user intervention (aside from the firstboot utility) when boot is complete, and all virtual consoles intended to provide a working login prompt should do so " 16:45:48 and "In most cases, the installed system must boot to a functional graphical environment without user intervention" 16:45:52 we have Alpha criteria for the graphical login prompt 16:46:00 yeah 16:46:04 proposed #agreed https://bugzilla.redhat.com/show_bug.cgi?id=627401 definite blocker, added as accepted blocker 16:46:05 Bug 627401: medium, low, ---, clumens, ON_QA, please create systemd default.target symlink pointing to /lib/systemd/system/runlevelX.target instead of /etc/systemd/system/runlevelX.target 16:46:07 ack 16:46:08 ack/nak 16:46:21 ack 16:46:57 ACK 16:47:07 #agreed https://bugzilla.redhat.com/show_bug.cgi?id=627401 definite blocker, added as accepted blocker 16:47:08 Bug 627401: medium, low, ---, clumens, ON_QA, please create systemd default.target symlink pointing to /lib/systemd/system/runlevelX.target instead of /etc/systemd/system/runlevelX.target 16:47:16 #topic https://bugzilla.redhat.com/show_bug.cgi?id=628239 16:47:17 Bug 628239: medium, low, ---, anaconda-maint-list, NEW, Fedora 14 Alpha "reduced graphics" creates vesa-using xorg.conf but doesn't blacklist nouveau 16:47:41 * poelcat needs to run 5 min before top of the hour... carry on w/o me 16:48:01 poelcat: Will do :-) 16:48:18 think we're near the end... 16:48:40 this one's a bit confusing, i thought installing in basic graphics mode *did* write nomodeset to the kernel config, but that doesn't match up with the tester's experience 16:48:47 we should probably test this one independently 16:48:57 Sounds like it to me as well 16:49:11 as for scope, this would impact any graphics uses who need to rely on the fallback vesa mode? 16:49:34 s/uses/users/ 16:49:46 yes, as described it would affect any radeon, intel or nvidia user who had to use basic graphics, the installed system would likely not be able to get to X 16:50:21 we added an alpha criterion - "The graphical boot menu for all installation images should include an entry which causes both installation and the installed system to use a generic, highly compatible video driver (such as 'vesa'). This mechanism should work correctly, launching the installer and attempting to use the generic driver" - after the breakage of this in alpha 16:50:41 I thought this sounded familiar 16:50:43 i note that i forgot to have that criterion state that the installed system must also be correctly configured with the vesa driver =) 16:50:59 adamw: Luckily, they aren't chiseled in stone :-p 16:51:12 you mean i've been doing all this chiselling for *nothing*?! 16:51:25 adamw: oh umm, yeah sorry 'bout that 16:51:41 proposed #action https://bugzilla.redhat.com/show_bug.cgi?id=628239 accepted blocker 16:51:42 Bug 628239: medium, low, ---, anaconda-maint-list, NEW, Fedora 14 Alpha "reduced graphics" creates vesa-using xorg.conf but doesn't blacklist nouveau 16:51:43 i think it's a logical extension of that criterion, so i'd propose we update the criterion, and if this bug is actually as described, it'd be a blocker 16:51:55 ACK 16:52:00 agreed on both points 16:52:05 well, i'd like to confirm the bug before accepting it 16:52:13 so pending test results 16:52:15 ? 16:52:17 but we can accept it tentatively while testing, sure 16:52:31 MODIFIED proposed #action https://bugzilla.redhat.com/show_bug.cgi?id=628239 propose update to criteria and then re-evaluate bug in light of critiera at next meeting 16:52:32 Bug 628239: medium, low, ---, anaconda-maint-list, NEW, Fedora 14 Alpha "reduced graphics" creates vesa-using xorg.conf but doesn't blacklist nouveau 16:52:38 ack/nak 16:52:41 ACK 16:52:59 ack away 16:53:09 ack 16:53:09 #action https://bugzilla.redhat.com/show_bug.cgi?id=628239 propose update to criteria and then re-evaluate bug in light of critiera at next meeting 16:53:10 Bug 628239: medium, low, ---, anaconda-maint-list, NEW, Fedora 14 Alpha "reduced graphics" creates vesa-using xorg.conf but doesn't blacklist nouveau 16:53:22 #topic https://bugzilla.redhat.com/show_bug.cgi?id=629719 16:53:23 Bug 629719: medium, medium, ---, anaconda-maint-list, NEW, FormatCreateError: ('invalid device specification', '/dev/md127p3') 16:53:27 last one... go team! 16:53:52 so this appears to be BIOS RAID 16:54:08 which we have beta criteria for ... 16:54:11 "The installer must be able to create and install to software, hardware or BIOS RAID-0, RAID-1 or RAID-5 partitions for anything except /boot " 16:54:24 #action adamw to update alpha criterion covering vesa driver to cover installed system as well as installer 16:54:25 we'll need to circle back on the bz to check what type of BIOS RAID configuration is present 16:54:39 yeah, but it seems like at least two people have hit this 16:54:50 Looks likie a blocker to me 16:54:55 "2 RAID1 disks" ... so that's a sane configuration 16:55:08 yep, Ben specifies a covered configuration 16:55:15 given that i'd say we should accept it for now 16:55:21 proposed #action https://bugzilla.redhat.com/show_bug.cgi?id=629719 accept as blocker 16:55:22 Bug 629719: medium, medium, ---, anaconda-maint-list, NEW, FormatCreateError: ('invalid device specification', '/dev/md127p3') 16:55:48 ack/nack 16:55:53 he *did* stick his /boot on RAID which we say we don't support, but actually, that shouldn't break installation at that point, so i'd say it's irrelevant in this case 16:55:59 ack 16:56:00 ACK 16:56:09 #action https://bugzilla.redhat.com/show_bug.cgi?id=629719 accept as blocker 16:56:10 Bug 629719: medium, medium, ---, anaconda-maint-list, NEW, FormatCreateError: ('invalid device specification', '/dev/md127p3') 16:56:16 #topic open discussion 16:56:21 great job... gotta run 16:56:25 i'll send recap later 16:56:26 Thanks again for all your hard works folks! 16:56:31 We couldn't do this without you! 16:56:34 question - is systemd settling down? 16:56:46 Seems to be, in my limited view 16:56:46 poelcat: thank you! 16:56:55 * jsmith hasn't run into any more problems with it 16:57:14 But I haven't done anything really crazy with it yet, either 16:57:15 i'm not aware of any major bugs, though the backward compatibility stuff isn't all done yet 16:57:23 thanks poelcat 16:57:42 Adamw's got a busy tuesday lined up to put it through the paces 16:57:59 alternatively, i'll call in sick and go golfing 16:58:15 possibly with cranes maska 16:58:31 that guy has a horrible slice 16:58:38 (and doesn't own clubs) 16:58:48 And never tips his caddy 16:58:56 hehe 16:58:58 geez, the nerve 16:59:15 oh, hey, while we're at it, i got an actual open discussion topic\ 16:59:18 lemme find the bug 16:59:19 alright ... well, same here ... I've not seen horrible results during normal use 16:59:32 adamw: Find away! 17:00:17 damn, can't...the bug i'm thinking of is the bug for adding a boot menu entry for basic graphics driver to live images 17:00:32 we basically agreed that they should have it just like the anaconda images do 17:00:43 and i actually wrote the new alpha criterion to cover all images, including live 17:01:07 so if we can semi-retroactively apply that new alpha criterion to f14 beta, live images not having a 'basic video driver' option should be a blocker 17:01:50 aha, found it - https://bugzilla.redhat.com/show_bug.cgi?id=608992 17:01:51 Bug 608992: medium, low, ---, dhuff, NEW, Add "Boot system with basic video driver" option at the initial screen 17:01:59 ah, I recall this 17:02:46 I think dhuff is only co-maintaining this package now? 17:03:11 * jlaska checks pkgdb 17:03:27 hmm, he's still listed as the owner 17:03:39 but a lot of others have commit access -- https://admin.fedoraproject.org/pkgdb/acls/name/livecd-tools 17:03:59 we may just want to reach out to him so he understands the request/criteria etc... 17:04:01 yeah, we could add some CCs 17:04:07 so this isn't lost in bz email spam land 17:04:12 Sounds like a good idea 17:04:17 I can ping him 17:04:25 Thanks jlaska 17:04:26 what do you guys think of making this a beta blocker? am i being too creative with the retroactive criteria application? :) 17:04:38 adamw: No, I think it's important 17:04:51 (we decided this should be an alpha blocker, but since the alpha was already done, i added it to the f15 alpha criteria, it's not technically in the f14 criteria) 17:05:10 Let's see if we can't get it done for the Beta 17:05:17 ok...jlaska? 17:05:18 well, let's see what kind of work will be required 17:05:30 it's not that bad, we've already looked at it 17:05:32 if there is significant resource contention/pushback ... we'll revisit 17:05:49 it's really just adding a bootloader menu option, that's slightly 'weird' because it's not grub, but it's not actually complex or dangerous 17:06:10 so we should be in good shape then 17:06:14 I'll ping huff after the meeting 17:06:30 we already have multiple bootloader menu options for the live image, all this needs is adding another one, which isn't a stretch. 17:06:32 cool 17:06:44 so, shall i make it a blocker? we can drop it later if we change our minds i guess.\ 17:07:02 that'd be my suggestion, yeah 17:07:27 WORKSFORME 17:07:27 ok 17:07:59 * jlaska pinged 17:08:06 alright ... #endmeeting time? 17:08:24 60 seconds ... 17:08:31 * jlaska lights fuse 17:08:48 ok, done 17:08:51 endmeeting is good for me 17:09:07 thanks all, and thanks to poelcat for speeding us through the agenda :) 17:09:24 #endmeeting