17:00:59 <tflink> #startmeeting F16-blocker-review 17:00:59 <zodbot> Meeting started Fri Aug 26 17:00:59 2011 UTC. The chair is tflink. Information about MeetBot at http://wiki.debian.org/MeetBot. 17:00:59 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic. 17:01:07 <tflink> #meetingname F16-blocker-review 17:01:07 <zodbot> The meeting name has been set to 'f16-blocker-review' 17:01:20 <tflink> #topic Roll Call 17:01:29 * jsmith is here (may be lurking part of the time) 17:01:29 <tflink> so, who all do we have today? 17:01:51 <tflink> and who wants to volunteer to lead if my internet goes out? 17:02:09 <tflink> of all the days for my ISP to be working on my line ... 17:04:48 <tflink> anyone else here? 17:04:58 <tflink> adamw? 17:05:54 * tflink isn't sure we can really do this with 2 people 17:06:01 <tflink> s/can/should 17:07:16 <jsmith> Especially if I'm trying to juggle this work + other items on my plate 17:08:21 <tflink> and I might have to leave early :-/ 17:09:27 <tflink> I'll give it another 10 minutes and see what happens 17:09:33 <tflink> we may have to postpone the meeting until monday 17:09:56 <tflink> but there are a lot of proposed blockers - I'd rather not leave them until next week 17:10:10 * tflink doesn't love 4+ hour blocker review meetings 17:10:37 <tflink> the current list is still pointing at alpha, but I have a temp list up on the wiki - https://fedoraproject.org/wiki/User:Tflink/Current_Release_Blockers 17:13:22 * jsmith looks 17:14:27 <jsmith> Looks like the majority of these are anaconda-related... any chance we can chase down a couple of the anaconda devs to help us? 17:14:51 <tflink> good question, will check 17:17:04 <tflink> bcl: are you able to stick around for the whole meeting? 17:17:09 <tflink> we're pretty short-handed today 17:17:24 <bcl> yep. clumens is out so I'm on deck :) 17:18:24 * tflink is still hoping for one more person so we have 3 full people 17:19:40 <tflink> do we have 3 full people? 17:20:02 <jsmith> I can try to shift my workload a bit and be more of a full person 17:20:07 <bcl> I'm kinda hungry actually ;) 17:20:21 <tflink> and still no adamw? :-/ 17:20:33 <tflink> well, lets get started and see how this goes 17:20:44 <tflink> #topix Introduction 17:20:50 <tflink> #topic Introduction 17:21:11 <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:21:22 <tflink> #link https://fedoraproject.org/wiki/QA:SOP_Blocker_Bug_Meeting 17:21:30 <tflink> #link https://fedoraproject.org/wiki/User:Tflink/Current_Release_Blockers 17:21:48 <tflink> OK, time for some proposed beta blockers 17:22:07 <tflink> #topic https://bugzilla.redhat.com/show_bug.cgi?id=723303 17:22:08 <buggbot> Bug 723303: high, unspecified, ---, dlehman, MODIFIED, device /dev/mapper/tmp--VolGroup01-xxxx does not exist 17:22:15 <tflink> #info device /dev/mapper/tmp--VolGroup01-xxxx does not exist 17:22:42 <tflink> oh, useful links that are going to mess up the meeting notes 17:22:50 <tflink> #link https://fedoraproject.org/wiki/Fedora_16_Beta_Release_Criteria 17:22:58 <pjones> dlehman says it's a beta blocker in #c6 17:22:59 <tflink> #link https://fedoraproject.org/wiki/Fedora_16_Alpha_Release_Criteria 17:23:08 <pjones> (also that it's fixed in #c10 ) 17:23:19 <jsmith> +1 for Beta Blocker 17:23:49 <bcl> generally, if it has been fixed already I vote +1 17:24:00 <tflink> this might be more final material 17:24:09 <tflink> oh, has it been fixed? 17:24:09 <pjones> it's fixed either way. 17:24:14 <pjones> that's why it's in MODIFIED. 17:24:37 <tflink> sorry, a little slow today I guess 17:24:38 <jsmith> Doesn't it hit criteria "installer must be able to successfully complete an upgrade installation from a clean, fully updated default installation"? 17:24:47 <pjones> jsmith: no 17:24:55 <tflink> it's a custom layout 17:24:58 <pjones> jsmith: it only hits on a fresh install 17:25:01 <jsmith> Ah, gotcha 17:25:14 <tflink> if it were a default partitioning option, it would though 17:25:17 <jsmith> I missed that -- thought it was an upgrade due to the existing LVs 17:25:34 * jsmith should read things closer next time 17:25:43 <pjones> so I don't think it actually meets any blocker criteria - but it's still fixed ;) 17:25:48 <tflink> proposed #agreed - 723303 - AcceptedBlocker for F16Final since it's a custom layout, AcceptedNTH for F16Beta since fix is already in 17:26:00 <pjones> tflink: +1 17:26:05 <jsmith> ACK 17:26:39 <tflink> #agreed - 723303 - AcceptedBlocker for F16Final since it's a custom layout, AcceptedNTH for F16Beta since fix is already in 17:26:51 <tflink> #topic https://bugzilla.redhat.com/show_bug.cgi?id=725757 17:26:52 <buggbot> Bug 725757: unspecified, unspecified, ---, akozumpl, MODIFIED, NameError: name 'setupProgressDisplay' is not defined 17:27:01 <tflink> #info NameError: name 'setupProgressDisplay' is not defined 17:27:35 <bcl> +1 17:27:42 <pjones> +1 for beta blocker, though again this should be fixed already. 17:28:00 <jsmith> +1 from me as well 17:28:39 * tflink is trying to find a criteria that is being violated 17:29:14 <pjones> * This impacts the F16 Beta release criteria regarding installation automation 17:29:14 <pjones> - "Any installation method or process designed to run unattended must do so 17:29:15 <pjones> (there should be no prompts requiring user intervention) " 17:29:16 <bcl> it's in the bug 17:29:17 <pjones> (from the bug) 17:30:21 <tflink> proposed #agreed - 725757 - AcceptedBlocker: Any installation method or process designed to run unattended must do so (there should be no prompts requiring user intervention) 17:30:29 <tflink> #agreed - 725757 - AcceptedBlocker: Any installation method or process designed to run unattended must do so (there should be no prompts requiring user intervention) 17:30:44 <tflink> we already had several +1's - I assumed that meant acks, too 17:30:57 <tflink> #topic https://bugzilla.redhat.com/show_bug.cgi?id=727522 17:30:58 <buggbot> Bug 727522: unspecified, unspecified, ---, msivak, MODIFIED, unable to install using nfs repo by askmethod 17:31:05 <tflink> #info unable to install using nfs repo by askmethod 17:31:25 <tflink> criteria -> The installer must be able to use the HTTP, FTP and NFS remote package source options 17:31:30 <tflink> pretty clear cut beta blocker, to me 17:31:57 <tflink> proposed #agreed - 727522 - AcceptedBlocker - The installer must be able to use the HTTP, FTP and NFS remote package source options 17:32:44 <pjones> yeah, looks like a clear case, and it happens to be fixed already. 17:32:46 <pjones> +1 from me. 17:32:50 <bcl> +1 17:32:59 <jsmith> ACK 17:33:00 <dgilmore> +1 17:33:05 <tflink> #agreed - 727522 - AcceptedBlocker - The installer must be able to use the HTTP, FTP and NFS remote package source options 17:33:17 <tflink> #topic https://bugzilla.redhat.com/show_bug.cgi?id=727814 17:33:18 <buggbot> Bug 727814: unspecified, unspecified, ---, dlehman, MODIFIED, F16 Alpha TC1 installer crash | LUKSError: luks device not configured 17:33:25 <tflink> #info F16 Alpha TC1 installer crash | LUKSError: luks device not configured 17:34:02 <pjones> I'm not convinced this meets any criteria, but since it's fixed already I don't really care. 17:34:13 <tflink> nth for beta, then? 17:34:17 <pjones> yeah 17:34:21 <jsmith> works for me 17:34:22 <tflink> I can't think of any criteria either 17:34:25 <bcl> sure. more like GoingToHave 17:34:29 <pjones> I mean, you just have to play without running in to any koopa troopas, and then it works fine. 17:35:06 <tflink> proposed #agreed - 727814 - RejectedBlocker - doesn't hit any of the release criteria. AcceptedNTH - annoying and already fixed 17:36:58 <tflink> using implied acks from pjones, jsmith and bcl 17:37:03 <tflink> #agreed - 727814 - RejectedBlocker - doesn't hit any of the release criteria. AcceptedNTH - annoying and already fixed 17:37:05 <bcl> :) 17:37:13 <jsmith> WORKSFORME 17:37:21 <tflink> #topic https://bugzilla.redhat.com/show_bug.cgi?id=728122 17:37:22 <buggbot> Bug 728122: medium, unspecified, ---, akozumpl, MODIFIED, upgrade failed from f15 to f16, Dispatch error:cannot reschedule step 'language' from 'done' to 'scheduled' 17:37:30 <tflink> #info upgrade failed from f15 to f16, Dispatch error:cannot reschedule step 'language' from 'done' to 'scheduled' 17:37:52 <bcl> +1 upgrades are supposed to work, or at least finish ;) 17:37:58 <jsmith> +1 from me 17:38:18 <pjones> +1 (and it also happens to be fixed.) 17:38:23 <tflink> yep, hits The installer must be able to successfully complete an upgrade installation 17:38:26 <tflink> from a clean, fully updated default installation (from any official install 17:38:29 <tflink> medium) of the previous stable Fedora release, either via preupgrade or by 17:38:32 <tflink> booting to the installer manually. The upgraded system must meet all release 17:38:53 <tflink> proposed #agreed - 728122 - AcceptedBlocker - 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:39:25 <adamw> oh, man, i suck. good thing you guys don't. 17:39:27 * tflink is going off of implied acks and will continue to do so 17:39:29 <pjones> +1 17:39:34 * adamw stops screwing with his web server and gets in the meeting 17:39:54 <tflink> finally :) 17:40:11 <bcl> welcome to the party 17:40:29 <tflink> #agreed - 728122 - AcceptedBlocker - 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:40:40 <tflink> #topic https://bugzilla.redhat.com/show_bug.cgi?id=728188 17:40:41 <buggbot> Bug 728188: medium, unspecified, ---, akozumpl, MODIFIED, upgrade failed from f15 to f16, Dispatch error:cannot reschedule step 'findinstall' from 'skipped' to 'requested' 17:40:49 <bcl> ditto 17:40:51 <tflink> #info upgrade failed from f15 to f16, Dispatch error:cannot reschedule step 'findinstall' from 'skipped' to 'requested' 17:40:57 <tflink> wait, did I just do the same bug twice? 17:41:08 <tflink> nvm 17:41:22 <pjones> looks that way. 17:41:24 <tflink> proposed #agreed - 728188 - AcceptedBlocker - 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:41:34 <adamw> ack! 17:41:40 <bcl> no, they're just very similar. 17:41:45 <jsmith> ACK 17:41:58 <tflink> #agreed - 728188 - AcceptedBlocker - 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:42:08 <tflink> #topic https://bugzilla.redhat.com/show_bug.cgi?id=728301 17:42:09 <buggbot> Bug 728301: unspecified, unspecified, ---, anaconda-maint-list, ASSIGNED, F16 Alpha TC1 installer | entering secondary LUKS passphrase => unknown filesystem 17:42:15 <tflink> #info F16 Alpha TC1 installer | entering secondary LUKS passphrase => unknown filesystem 17:42:38 <pjones> yeah, so, +1 here as well. 17:42:50 <bcl> +1 17:42:58 <sgallagh> +1 17:43:07 <tflink> this sounds similar to bug 723303 17:43:07 <jsmith> +1 17:43:08 <buggbot> Bug https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=723303 high, unspecified, ---, dlehman, MODIFIED, device /dev/mapper/tmp--VolGroup01-xxxx does not exist 17:43:09 <adamw> how common are secondary passphrases? 17:43:19 * adamw hadn't come across them before 17:43:21 <tflink> not quite, now that I look at it harder 17:43:50 <sgallagh> adamw: Common enough that it's going to hurt some people (myself included) 17:44:07 <tflink> I'm probably +1 NTH on this one, not sure about blocker though 17:44:17 <sgallagh> adamw: It's fairly common to set up a / and /home encrypted partition 17:44:42 <sgallagh> tflink: I'd say release blocker but not beta blocker 17:44:47 <adamw> oh, so if you use one passphrase only /home gets unlocked? didn't know you could do that... 17:44:49 * jsmith is OK with NTH 17:44:53 <tflink> so this is when you have different passphrases for / and /home? 17:44:55 <adamw> i think final is appropriate 17:45:21 <adamw> under the combination of final criterion "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 " and the alpha criterion "the system's gotta boot" (paraphrased) 17:45:32 <bcl> It's already fixed. +1 17:45:42 <adamw> "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 partitions when the correct passphrase 17:45:42 <adamw> is supplied. The firstboot utility must be able to create a working user account " 17:45:53 <adamw> so..+1 beta nth final blocker 17:46:02 <jsmith> ACK 17:46:04 <tflink> proposed #agreed - 728301 - AcceptedBlocker for F16Final - 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 17:46:15 <tflink> oh, NTH 17:46:33 <tflink> proposed #agreed - 728301 - AcceptedBlocker for F16Final - 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. AcceptedNTH for F16Beta 17:46:42 <jsmith> ACK 17:46:53 <adamw> ack 17:47:08 <adamw> jsmith's like a tommy gun - ackackackackackackackack... 17:47:27 <sgallagh> ack 17:47:34 <jsmith> adamw: Don't tempt me to make this meeting any longer than it needs to be :-p 17:47:38 <tflink> #agreed - 728301 - AcceptedBlocker for F16Final - 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. AcceptedNTH for F16Beta 17:47:47 <tflink> #topic https://bugzilla.redhat.com/show_bug.cgi?id=728923 17:47:49 <buggbot> Bug 728923: unspecified, unspecified, ---, akozumpl, MODIFIED, Serial console is not configured 17:47:57 <tflink> #info Serial console is not configured 17:48:13 <adamw> so, serial console is kinda in limbo atm 17:48:26 <adamw> it's marked as 'alpha' in the matrix but we all agreed we didn't really care about it for alpha 17:48:32 <adamw> so do we want it to block beta, final or nothing? 17:48:42 <sgallagh> Lack of serial console is going to be a serious barrier to server adoption. 17:48:52 <jsmith> I think it's certainly important for final 17:49:07 <jsmith> but I don't know how much work it might take to get it up to snuff 17:49:14 <sgallagh> I personally know of several companies that build appliances atop Fedora that will need serial access 17:49:25 <tflink> we could use this for beta: 17:49:27 <tflink> 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 unintended user intervention when boot is complete, and all virtual consoles intended to provide a working login prompt should do so 17:49:39 <tflink> it's a bit of a stretch but not too bad 17:49:52 <adamw> well, that criterion really wasn't written for serial consoles, so i'd feel more comfortable adjusting the criteria if we want this to block beta 17:49:59 <adamw> (which is fine, it's easy to do) 17:50:14 <tflink> so then the question becomes beta or final? 17:50:16 <adamw> just a question of what we think is appropriate... 17:50:17 <adamw> yeah. 17:50:22 <bcl> moot. +1 17:50:31 <sgallagh> I vote NTH beta, Blocker Final 17:50:35 <adamw> bcl: well for _this_ case it's moot, but we have to think about the future too 17:50:52 <adamw> bcl: imagine we're stuck on F17 Beta RC4, everything else works but serial console is broken: do we slip the release a week? 17:51:03 <tflink> there is a fix available, too 17:51:07 <bcl> obviously :) 17:51:24 <pjones> adamw: we don't have to do that in this meeting though. 17:51:36 <tflink> adamw: I'm about to lose my internet connection since my ISP is working on my line. can you take over? 17:51:38 <pjones> right now we need to decide about bugs. we can decide about general policy at another time. 17:51:47 <tflink> I'm +1 Beta NTH either way 17:52:01 <adamw> pjones: the idea is that we only decide about bugs according to general policy, to avoid things being completely subjective; that's the point of having a policy 17:52:06 <tflink> and +1 final blocker 17:52:11 <pjones> adamw: that's insane. 17:52:21 <adamw> if we go back to 'well, there's a fix in already, so let's call it a blocker because we don't have to worry about fixing it!", we may as well throw the criteria out the window 17:52:52 <bcl> sounds good to me. Really. it's fixed. move on. 17:52:58 <pjones> that's complete nonsense, but it's also not something we should argue about here and now. 17:53:03 <sgallagh> adamw: That also doesn't work because if the fix is bad or causes a regression, it may need to be backed out 17:53:16 <adamw> pjones: not really? the fact that this bug is proposed as a blocker makes it clear we have no criteria covering serial consoles. we have no kind of basis on which to decide whether this is a blocker unless we know what we want our policy to be. 17:53:28 <tflink> proposed #agreed - 728923 - AcceptedNTH - there are currently no criteria to cover this bug but it is an issue and a fix is ready 17:53:28 <pjones> adamw: false. 17:53:29 <adamw> if you just want to move on, that would entail rejecting this bug as a blocker, because we have no kind of basis to accept it. 17:53:37 <pjones> again, false. 17:53:40 <adamw> why? 17:53:47 <pjones> we can make a decision without it applying to everything. we really can. 17:53:47 <adamw> on what grounds can we currently accept it as a blocker? 17:54:08 <pjones> also - we don't need to agree that it's a blocker, and as you'll see if you look, we didn't. 17:54:10 <sgallagh> adamw: Fails to boot to a usable system in a headless environment? 17:54:19 <adamw> sgallagh: where's the criterion for that? 17:54:28 * tflink forgot to tally up the votes 17:54:35 <dgilmore> adamw: should be able to log into a system post install 17:54:42 <adamw> pjones: if you're fine with taking it as NTH and not a blocker for beta or final, we can move on. 17:54:43 <pjones> (or rather aren't considering doing so) 17:54:59 <pjones> of course I'm fine with that. 17:55:35 <tflink> we could leave it as a proposed blocker, then and revisit next wee 17:55:37 <tflink> week 17:55:42 <dgilmore> adamw: i say its a blocker, since we should be able to log into a system post install, i actually have a bunch of headless hardware 17:55:48 <pjones> NTH is fine. It's fixed either way. 17:55:51 <tflink> dgilmore: for beta? 17:55:51 <adamw> propose #agreed 728923 acceptednth: no criteria coverage for serial console, will revisit for blocker status if not fixed next week 17:56:12 <tflink> ack 17:56:31 <tflink> #chair adamw 17:56:31 <zodbot> Current chairs: adamw tflink 17:56:39 <dgilmore> tflink: yes 17:56:50 <adamw> dgilmore: if you were gonna use that criterion this should have been an alpha blocker, but none of us wanted it to be... 17:57:32 <adamw> so i count ack from me, tflink, implied from pjones, anyone really want to make this a blocker or shall we move on? 17:58:01 <pjones> bcl also agreed to it while you were obsessing about criteria. 17:58:13 <dgilmore> adamw: im +1 for blocker 17:58:21 <adamw> pardon me for wanting to have an actual basis on which to make decisions. 17:58:22 <bcl> ack ack ack :) 17:58:27 <adamw> okay. 17:58:30 <jsmith> dgilmore: Beta blocker, or final? 17:58:33 <adamw> #agreed 728923 acceptednth: no criteria coverage for serial console, will revisit for blocker status if not fixed next week 17:58:37 <dgilmore> jsmith: beta 17:58:39 <adamw> jsmith: he's outvoted and we're all going grey. =) 17:58:52 <bcl> adamw: really, this is a bug focused meeting, not a criteria meeting. add it to a list and discuss in appropriate meeting. 17:58:56 <dgilmore> adamw: i say we have a policy but i guess im outvoted here 17:59:02 <bcl> maybe this is why these meetings take 6 hours? 17:59:05 <tflink> #topic https://bugzilla.redhat.com/show_bug.cgi?id=729558 17:59:06 <buggbot> Bug 729558: unspecified, unspecified, ---, akozumpl, MODIFIED, upgrade without a kickstart displays steps it shouldn't 17:59:13 <tflink> #info upgrade without a kickstart displays steps it shouldn't 17:59:33 <sgallagh> -1 Blocker, +1 NTH. 18:00:16 <tflink> does this break anything? 18:00:18 <pjones> +1 NTH, but again this is a fixed bug 18:00:23 <tflink> or just an annoyance 18:00:39 <pjones> tflink: it's possible that it could change some settings that make your installation inconsistent and cause problems. 18:00:44 <bcl> yeah, NTH, fixed, +1 18:00:50 <jsmith> +1 NTH 18:00:52 <tflink> definitely +1 NTH 18:01:40 <tflink> proposed #agreed - 729558 - AcceptedNTH - could cause upgrade issues. RejectedBlocker - no clear criteria violation 18:02:25 <adamw> ack 18:02:27 <jsmith> ACK 18:02:32 * tflink notes that he is not going to get warning when he gets disconnected 18:02:48 <tflink> #agreed - 729558 - AcceptedNTH - could cause upgrade issues. RejectedBlocker - no clear criteria violation 18:02:49 <sgallagh> ack 18:02:59 <tflink> #topic https://bugzilla.redhat.com/show_bug.cgi?id=730415 18:02:59 <bcl> tflink: send us an ack every 30 seconds ;) 18:03:00 <buggbot> Bug 730415: unspecified, unspecified, ---, bcl, MODIFIED, kickstart with user --name=blah results in traceback 18:03:11 <tflink> #info kickstart with user --name=blah results in traceback 18:03:11 <adamw> tflink: what list are you working from? 18:03:14 <tflink> bcl: ack 18:03:15 <adamw> current_release_blockers looks wrong 18:03:22 <tflink> adamw: https://fedoraproject.org/wiki/User:Tflink/Current_Release_Blockers 18:03:28 <adamw> ah, k 18:03:33 <tflink> I couldn't get ahold of jlaska to update his script 18:03:46 <tflink> update the args to his script, rather 18:04:02 <adamw> so we have a -test list discussion going for kickstart criteria 18:04:10 <adamw> seems like everyone broadly agrees a really basic kickstart should work by beta 18:04:11 <bcl> yeah, this is at least NTH and hits kickstart users who specify users. 18:04:17 <tflink> did we ever come to a conclusion on that one? 18:04:22 <adamw> doesn't just about any kickstart specify users? 18:04:32 <bcl> no 18:04:34 <jsmith> Not all of them do 18:04:41 <jsmith> My kickstarts don't 18:04:51 <bcl> eg. the ones used for spins don't. 18:04:55 <dgilmore> adamw: ive never specified users in kickstarts 18:04:57 <adamw> ah, true. 18:05:47 <adamw> so...if it's not a really basic feature, i guess i feel more final blocker-y than beta 18:06:29 <pjones> I cold see the argument for NTH. It's fixed in any case. 18:06:38 <adamw> nth for beta, sure 18:06:42 <adamw> worth fixing 18:07:04 <adamw> anyone else? 18:07:09 <jsmith> +1 NTH 18:07:22 <sgallagh> +1 NTH 18:07:39 <dgilmore> +1 nth 18:08:22 <pjones> +! NTH 18:08:22 <adamw> propose #agreed 730415 acceptednth for beta, no blocker determination as we did not finalize kickstart criteria 18:08:36 <dgilmore> adamw: ack 18:08:38 <jsmith> ACK 18:08:39 <adamw> so if anyone's worried about blocker status speak up, or else i'll go with that 18:08:40 <sgallagh> ack 18:09:00 <adamw> #agreed 730415 acceptednth for beta, no blocker determination as we did not finalize kickstart criteria 18:09:08 <adamw> oh, was tim being secretary? or is someone else doing that? 18:09:18 <jsmith> adamw: He asked you to :-) 18:09:40 <adamw> jsmith: no, i'm running the meeting now, but i mean - updating the bugs as we go 18:09:46 <adamw> chair, secretary =) 18:09:50 <jsmith> adamw: I think he was doing that, yes :-) 18:09:56 <jsmith> adamw: But I'm not sure 18:09:59 <adamw> okay, i guess i'll catch up with it later. 18:10:09 <adamw> #topic http://bugzilla.redhat.com/show_bug.cgi?id=730857 18:10:10 <buggbot> Bug 730857: medium, unspecified, ---, clumens, MODIFIED, Traceback when installing a package at the end of anaconda installation 18:10:53 <adamw> so, this is mostly kickstart stuff again? 18:11:16 <adamw> question is how critical it is to be able to install packages in kickstart %post, i guess 18:11:42 <sgallagh> Yeah, what's the value in installing packages in %post as opposed to specifying them in the package list? 18:11:49 <dgilmore> adamw: i think its pretty common 18:11:52 <sgallagh> Or is this for installing non-Fedora RPMs? 18:12:02 <jsmith> Or, more specifically, install packages via *yum* 18:12:07 <jsmith> (at least as I read it) 18:12:23 <pjones> honestly it's hard to believe this is even a bug. 18:12:38 <adamw> again we're establishing the kickstart criteria at present, so if anyone has strong feelings on whether this should be a blocker, and beta / final, that can feed in 18:12:39 <dgilmore> fedora infrastructure kickstarts install some stuff in %post using yum 18:12:52 <jsmith> -1 blocker, +1 NTH 18:13:03 <dgilmore> adamw: +1 nth beta +1 final blocker 18:13:15 <bcl> +1 nth 18:13:29 <sgallagh> +1 nth beta, I'm not sure about final blocker. 18:13:42 <adamw> so it kinda feels like people are leery of making kickstart issues blockers. 18:14:08 <jsmith> adamw: In general, I'm fine for *some* kickstart issues to be blockers, but I think this qualifies as a corner case 18:14:09 <pjones> I wouldn't agree with that as a general statement. 18:14:14 <adamw> okay 18:14:16 <bcl> well, %post is pretty wide open for breaking things. 18:14:23 <adamw> so it's more that these are pretty non-critical 18:14:35 <jsmith> Yeah, I think that's a fair statement 18:14:39 <sgallagh> yes 18:14:40 <pjones> yeah, I find it difficult to classify things in %post as major problems. 18:14:42 <bcl> right 18:14:43 <adamw> so, didn't really get enough votes for blocker, so: 18:15:19 <adamw> propose #agreed 730857 acceptedNTH, rejectedblocker for beta, no decision on final blocker: it's good to fix this as it's an installer issue, but it's not a critical case 18:15:40 <sgallagh> ack 18:15:46 <dgilmore> sure 18:16:14 <adamw> alright, with implied acks 18:16:17 <adamw> #agreed 730857 acceptedNTH, rejectedblocker for beta, no decision on final blocker: it's good to fix this as it's an installer issue, but it's not a critical case 18:16:33 <adamw> #topic https://bugzilla.redhat.com/show_bug.cgi?id=731529 18:16:34 <buggbot> Bug 731529: high, unspecified, ---, pjones, NEW, grub making uefi calls without aligning stack pointer 18:16:56 <adamw> this one's pretty straightforward: we require EFI installs to work at beta, this bug makes it not work on quite a lot. 18:16:56 <pjones> I need to update this to modified to reflect the current build 18:17:04 <adamw> so, +1 blocker for me. 18:17:10 <sgallagh> +1 beta blocker 18:17:21 <jsmith> Pretty clear to me as well, +1 beta blocker 18:17:28 <pjones> obviously I'm for it. 18:17:28 <bcl> +1 18:17:41 <dgilmore> +1 blocker 18:18:14 <adamw> #agreed 731529 acceptedblocker: "The installer must boot and run on systems using EFI other than Apple Macs" 18:18:25 <adamw> #topic "The installer must boot and 18:18:25 <adamw> run on systems using EFI other than Apple Macs " 18:18:27 <adamw> grr 18:18:29 <adamw> #undo 18:18:29 <zodbot> Removing item from minutes: <MeetBot.items.Topic object at 0xd14582c> 18:18:36 <adamw> #topic https://bugzilla.redhat.com/show_bug.cgi?id=728193 18:18:37 <buggbot> Bug 728193: medium, unspecified, ---, richard, NEW, preupgrade cannot retrieve repomd.xml 18:18:39 <adamw> lousy paste buffers... 18:19:00 <adamw> another pretty straightforward one, per the criterion cited in comment #5 18:19:07 <adamw> we require preupgrade to work at beta 18:19:14 <adamw> so, +1 blocker 18:19:15 <sgallagh> f14->f16? Do we support that? 18:19:22 <dgilmore> sgallagh: yes 18:19:26 <dgilmore> f14 and f15 18:19:30 <pjones> directly? 18:19:33 <dgilmore> yes 18:19:43 <sgallagh> The criteria only lists "the previous stable Fedora release" 18:19:52 <sgallagh> Not plural 18:19:58 <adamw> ooh, good catch. 18:20:13 <jsmith> Yeah, I thought the criterion was previous release 18:20:15 <adamw> indeed we don't require a +2 upgrade to work (though it's an 'aspiration')_ 18:20:40 <sgallagh> Among other things, I think we'd likely have a lot of serious issues going from 14->16, since upgrades could miss systemd conversion 18:20:42 <Viking-Ice> +1 18:20:45 <adamw> but i don't know if hongqing tested f15 to f16 and it worked, or only tested f14 18:21:01 <bcl> sgallagh: yeah 18:21:04 <adamw> so i guess we need info as to whether this affects f15 18:21:10 <pjones> we only know that one thing doesn't work; the bug doesn't have to do with the other thing. 18:21:25 <pjones> we need somebody to test f15->f16 and file it as another bug if broken. 18:21:35 <adamw> well, if it hits the same error, just add a comment 18:21:40 <pjones> sure. 18:21:50 <sgallagh> I'm -1 blocker unless this is proven to affect F15 18:21:52 <adamw> okay 18:21:55 <pjones> sgallagh: likewise 18:21:58 <adamw> NTH if it's f14 only? 18:22:08 <Viking-Ice> ack 18:22:11 <pjones> I won't disagree with NTH 18:22:11 <jsmith> ACK 18:22:12 <sgallagh> sure 18:22:29 <bcl> +1 nth 18:22:41 <adamw> propose #agreed 728193 need to know if this affects f15->f16 preupgrade as criterion only requires +1 upgrades to work. AcceptedNTH if it's F14-F16 only 18:22:53 <sgallagh> ack 18:23:10 <jsmith> ACK 18:23:25 <adamw> #agreed 728193 need to know if this affects f15->f16 preupgrade as criterion only requires +1 upgrades to work. AcceptedNTH if it's F14-F16 only 18:23:43 <adamw> #topic https://bugzilla.redhat.com/show_bug.cgi?id=724814 18:23:44 <buggbot> Bug 724814: unspecified, unspecified, ---, jforbes, ON_QA, qemu -device ? fails, breaks libvirt capabilities reporting (and thus virt-manager vm creation) 18:24:10 <adamw> so, this one's simply - you can't use f16 as a vm host 18:24:15 <adamw> or, well, you can, now there's an update that fixes it. 18:24:30 <adamw> but yeah, without the fix, you can't run any vms. 18:24:49 <sgallagh> I don't think that breaks any of our blocker criteria 18:24:52 <pjones> seems like NTH. 18:24:53 <adamw> criterion is "The release must boot successfully as a virtual guest in a situation where the virtual host is running the same release (using Fedora's current preferred virtualization technology) " 18:25:06 <adamw> i.e., we require vm host functionality to work at beta. 18:25:11 <pjones> this doesn't seem to violate that 18:25:17 <pjones> that seems to say guest has to work if host does. 18:25:29 <adamw> hum, i read it as 'both guest and host have to work', and i probably wrote it =) 18:25:38 <adamw> but i can go back and check the context... 18:25:45 <sgallagh> adamw: Yeah, I agree with that interpretation. 18:26:23 <pjones> I'm okay with counting it as that and maybe rewording the criteria to actually say that later ;) 18:26:24 <adamw> sigh. i could if we had a list search worth a damn. 18:26:34 <adamw> pjones: sure, i agree it's a bit ambiguous 18:26:41 <adamw> but i'm pretty sure we intended to require both to work 18:26:41 <sgallagh> +1 beta blocker 18:27:25 <sgallagh> Well, I can believe that the original meaning was "Must boot as a VM guest, but we won't consider it a blocker if it won't boot on Fedora N-1's version of KVM" 18:27:25 <adamw> jsmith: vote? 18:27:27 <jsmith> +1 beta blocker for me 18:27:47 <bcl> seems like a blocker to me. 18:27:55 <sgallagh> But I stand by my blocker vote 18:28:09 <adamw> sgallagh: nah, read the next criterion. it's just bad wording, pjones is right. 18:28:35 <adamw> #agreed 724814 acceptedblocker: "The release must boot successfully as a virtual guest in a situation where the virtual host is running the same release (using Fedora's current preferred virtualization technology)" 18:28:48 <adamw> #action adamw to propose better wording for the criterion to make it clear both host and guest functions must work 18:29:11 <adamw> okay, that's all the proposed blockers 18:29:14 <adamw> we have one proposed NTH 18:29:20 <adamw> and it's a doozy 18:29:22 <adamw> #topic http://bugzilla.redhat.com/show_bug.cgi?id=498207 18:29:23 <buggbot> Bug 498207: low, high, ---, rvykydal, ASSIGNED, DVD install defaults to ONBOOT=no leaving networking down after reboot 18:29:37 <adamw> apparently we're defaulting to networking being on! 18:29:49 <adamw> cue dancing unicorns, hot dogs, etc etc 18:30:01 <pjones> eh 18:30:12 <bcl> that's a pretty old bug 18:30:15 <adamw> so, as i voted in the bug, i'm definitely +1 nth if anaconda team wants to change this. 18:30:18 <adamw> bcl: yup, but a new change. 18:30:35 * jsmith is very definitively a +0 on this one 18:30:55 <pjones> certainly I'm not going to say "no" to NTH 18:31:01 <pjones> but at the same time... 18:31:04 <sgallagh> Correct me if I'm wrong, but this only applies to non-NM installs, yes? 18:31:10 <adamw> jsmith: i'm +1 on the basis that, if anaconda team wants to change it, let's change it now 18:31:21 <pjones> sgallagh: doesn't look that way... 18:31:31 * sgallagh has been corrected 18:31:37 <adamw> jsmith: i'm not voting +1 "this must be changed", but +1 "if anaconda team decides to change it, let it through beta freeze" 18:31:47 <jsmith> adamw: And I'm +0, as there are plenty of anaconda folks here that can vote for themselves, and they know a lot more than I do :-) 18:31:53 <bcl> I'd agree to that 18:32:08 <jsmith> adamw: I'm not voting against them, just saying I don't know enough to make a definitive vote for or against 18:32:11 <pjones> I mean, I don't know that anybody's going to get to it, but sure, +1 NTH 18:32:53 <bcl> radek has a patch for it. 18:32:58 <adamw> right 18:33:03 <adamw> that's why it's been proposed 18:33:04 <dgilmore> +1 nth 18:33:07 <adamw> https://www.redhat.com/archives/anaconda-devel-list/2011-August/msg00247.html 18:33:09 <tflink> +1 NTH 18:33:11 * sgallagh abstains 18:33:14 <adamw> bcl has been reviewing it. 18:33:30 <adamw> sorry, i should've made that clearer, as it's buried in comment #5,687 or something. =) 18:33:41 <bcl> +1 nth seems like network coming up would be a good feature :) 18:33:51 <tflink> https://bugzilla.redhat.com/show_bug.cgi?id=498207#c64 18:33:52 <buggbot> Bug 498207: low, high, ---, rvykydal, ASSIGNED, DVD install defaults to ONBOOT=no leaving networking down after reboot 18:34:34 <adamw> so, i think we got enough +1s for an acceptednth 18:34:47 <jsmith> adamw: See, you didn't need my vote anyway :-p 18:34:55 <adamw> #agreed 498207 acceptednth: if anaconda team decides to take radek's patch, it makes sense to take it into beta 18:35:13 <adamw> okay...that's everything on the list, i believe 18:35:29 <adamw> #topic open discussion 18:35:35 <adamw> anyone have any non-discussed bugs to bring up? 18:36:04 <jsmith> I'd just personally like to thank everyone for helping out, and not making this a four hour meeting :-) 18:36:14 <pjones> 498207 wasn't mentioned because I don't have a fix for it - trivial attempts to reproduce it haven't yielded any results, so... 18:36:22 <adamw> yup! if you're smart like me and showed half an hour late, it's only taken an hour =) 18:36:33 <adamw> pjones: wrong bug #? 18:36:38 <adamw> that's the networking one again 18:36:52 <pjones> er, yes 18:36:53 <pjones> 718722 18:36:56 <tflink> oh, there is the remaining proposed alpha blocker 18:37:30 <adamw> hey, he's back 18:37:53 <adamw> #topic http://bugzilla.redhat.com/show_bug.cgi?id=718722 18:37:54 <buggbot> Bug 718722: unspecified, unspecified, ---, pjones, NEW, Mismatched or corrupt version of stage1/stage2 18:37:57 * sgallagh has to leave 18:38:02 <adamw> so...yeah, this one still feels pretty fuzzy 18:38:07 <tflink> sgallagh: thanks for helping out 18:38:14 <adamw> maybe it'll affect upgrades once we fix the earlier issues with those? 18:38:34 <pjones> it's possible but unlikely 18:38:56 <adamw> i guess we can keep monitoring it, with an eye to dropping blocker status if it doesn't seem to be causing anyone but the original two reporters problems 18:38:58 <pjones> it seems like you can only actually hit it if you upgrade and copy stage2 files over old ones without running grub-install 18:39:14 <pjones> which is solid NOTABUG land. But I'm not completely convinced that's it either at this point. 18:39:22 <adamw> okay 18:39:28 <adamw> keeping it on the radar seems like the best idea? 18:39:32 <pjones> yeah. 18:39:35 <adamw> cool. 18:39:43 <pjones> anyway, figured I'd mention it for a heads up 18:39:55 <adamw> #agreed 718722 is still fuzzy, no clear reproducer: pjones is monitoring and trying to determine if it's a serious bug 18:40:04 <adamw> yeah, it was actually on the list, thanks for the catch 18:40:18 <adamw> #topic open floor 18:40:20 <tflink> accepted blocker, no? 18:40:24 <adamw> tflink: it already is one 18:40:37 <tflink> exactly - we didn't do accepted first 18:40:38 <adamw> tflink: i just didn't notice it on the list as it was above the proposed blockers 18:40:45 <tflink> ah, gotcha 18:40:54 <tflink> there is the one that got proposed as an alpha blocker 18:40:57 <tflink> https://bugzilla.redhat.com/show_bug.cgi?id=732164 18:40:58 <adamw> ah, fun 18:40:59 <buggbot> Bug 732164: unspecified, unspecified, ---, lkundrak, NEW, grub version in f16 alpha doesent detect md devices properly 18:41:06 <adamw> #topic https://bugzilla.redhat.com/show_bug.cgi?id=732164 18:41:07 <buggbot> Bug 732164: unspecified, unspecified, ---, lkundrak, NEW, grub version in f16 alpha doesent detect md devices properly 18:41:10 <tflink> after alpha release 18:41:49 <adamw> do we support /boot on raid? 18:42:03 <tflink> not sure 18:42:12 <bcl> yes, on RAID1 18:42:23 <adamw> k 18:42:30 <adamw> the criterion says "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 " so i guess we could tweak that a bit 18:43:08 <adamw> so, i'd be +1 final blocker per the final criterion cited in the bug, +1 beta blocker if we adjust that beta criterion to say /boot on RAID-1 is okay 18:43:12 <tflink> that was a grub limitation, no? 18:43:22 <tflink> the /boot on RAID? 18:43:24 <bcl> no 18:43:28 <tflink> dm-raid anyways 18:44:00 <bcl> maybe dmraid, I'm not sure how it's metadata is handled but mdraid with grub works fine. 18:44:07 <pjones> also note that that bug isn't about *booting* 18:44:10 <pjones> it's about writing the config file 18:44:28 <pjones> I think it produces a config file that will work, but also has a bunch of garbage stanzas 18:44:42 <adamw> "the installation went through and showed no error -> installation didnt boot" 18:45:00 <pjones> dgilmore: this is the thing you were looking at yesterday, right? 18:45:02 <adamw> (from the initial submission, end of the first paragraph) 18:45:12 <pjones> Oh, there's a fix in 1.99 18:45:13 <tflink> adamw: isn't /boot on raid final? 18:45:18 <dgilmore> pjones: not really 18:45:20 <pjones> so when I build that on monday/tuesday that should get fixed 18:45:26 <pjones> dgilmore: okay 18:45:37 <dgilmore> pjones: i had to replace the video card, and will have a bug later 18:45:40 <tflink> so that the "everything but /boot" is beta and everything else is final? 18:45:54 <adamw> no, that wasn't the intent 18:46:03 <pjones> I think the criteria is just outdated 18:46:07 <adamw> the intent was that we specifically require RAID to work at beta, but we except /boot because we didn't support it 18:46:13 <tflink> ok 18:46:23 <adamw> the final criterion is a catch-all, and /boot on RAID was not considered a 'workable partition layout' for its purposes 18:46:44 <adamw> but as pjones says, it seems a bit outdated now, we can revise it to say we support /boot on mdraid 18:46:54 <dgilmore> pjones: i did get the box to boot off of the lvm on raid10 18:46:54 <tflink> then +1 blocker pending criteria revision 18:47:04 <pjones> dgilmore: okay 18:47:19 <pjones> I'm +1 on this for final, certainly. 18:47:32 <pjones> anyway, I'm going to update the package to 1.99 final next week, and that should fix it. 18:47:41 <bcl> dgilmore: dlehman was having some success with odd grub2 boots (lvm I think) 18:47:47 <adamw> pjones: would you support updating the beta criteria to allow /boot on raid and hence make it a beta issue? 18:47:57 <pjones> adamw: in the future? yes. 18:48:00 <adamw> okay 18:48:02 <bcl> I think so, yes. 18:48:12 <adamw> with the criteria we have, here's a proposed... 18:48:12 <bcl> 'cause that's actully worked for quite a while now. 18:48:33 <pjones> what's our beta go/nogo date? 18:48:46 <adamw> proposed #acceptedblocker for final under criterion "The installer must be able to create and install to any workable partition 18:48:46 <adamw> layout using any file system offered in a default installer configuration, LVM, software, hardware or BIOS RAID, or combination of the above" as installer team now considers /boot-on-RAID-1 to be a workable layout 18:49:13 <adamw> pjones: 09-21, we have a while 18:49:16 <adamw> this is just the first meeting 18:49:22 <dgilmore> bcl: i suspect i know what my issue is 18:49:41 <tflink> ack 18:50:31 <adamw> ack/nack/patch anyone? 18:50:35 <adamw> oh 18:50:35 <pjones> adamw: yeah, okay 18:50:37 <adamw> and acceptednth for beta 18:50:46 <adamw> patch... 18:51:02 <adamw> proposed #acceptedblocker for final under criterion "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" as installer team now considers /boot-on-RAID-1 to be a workable layout. acceptednth for beta 18:51:04 <bcl> adamw: I think so. barring any technical reasons from grub2 18:51:04 <pjones> adamw: just wanted to make sure if this weather thing goes bad I wouldn't be delaying the beta if we required this bug 18:51:15 <adamw> bcl: we can revisit if you guys find there are problems 18:51:22 <bcl> nod 18:51:25 <pjones> I think this is going to be an easy bug. 18:51:30 <adamw> sure. 18:52:12 <adamw> bcl: right now this is dependent on the definition of 'workable partition layout', which really is determined by your team, so we can easily flip it to not-a-blocker if you decide it's not actually workable 18:52:43 <bcl> ok, cool. Just didn't want to get stuck if grub2 has a problems with certain configs. 18:53:00 <adamw> #agreed 732164 acceptedblocker for final under criterion "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" as installer team now considers /boot-on-RAID-1 to be a workable layout. acceptednth for beta 18:53:15 <adamw> okay 18:53:19 <adamw> let's try this again...=) 18:53:21 <adamw> #topic open floor 18:53:30 * pjones is going to go away now. 18:53:41 <tflink> adamw: are you secretarializing or am I? 18:53:55 <tflink> or some other volunteer? 18:53:55 <adamw> so i have one quickly while anaconda and releng are in the same room - we (qa) wanted to try making the beta 'rawhide acceptance' test point into TC1 instead 18:54:05 <adamw> tflink: either way is ok for me 18:54:16 <adamw> essentially, start the beta TCs a little earlier, as an experiment 18:54:25 <adamw> that way TC1 would be 08-31 18:54:32 <adamw> instead of 09-06 18:54:38 <dgilmore> adamw: do 2 tcs 18:54:43 <adamw> does that seem plausible, or giving anyone heart attacks? 18:54:43 <dgilmore> or just do it early 18:55:03 <adamw> dgilmore: well, we don't usually specify the *number* of TCs, it tends to be flexible depending on how broken they are 18:55:06 <bcl> I don't see any problem. I like more rather than less. 18:55:09 <adamw> but start a bit earlier than scheduled 18:55:14 <pjones> more composes seems fine 18:55:19 <dgilmore> adamw: im ok with it 18:55:48 <adamw> the background is that 'rawhide acceptance' is a pretty fuzzy test point - it's meant to be automated but in practice it isn't, so it really turns into a kinda non-transparent, partial TC run by our china team, so we figured 'let's just make it a real TC' 18:55:49 <jsmith> WORKSFORME 18:55:50 <adamw> cool 18:55:57 * pjones really goes, then 18:56:02 <adamw> thanks pjones! 18:56:16 * bcl goes to find food 18:56:35 <adamw> thanks for coming, everyone 18:56:41 * adamw sets fuse 18:57:13 <adamw> 3...2... 18:57:25 <adamw> 1! 18:57:29 <adamw> #endmeeting