15:02:00 #startmeeting fedora-qa 15:02:00 Meeting started Mon Oct 8 15:02:00 2012 UTC. The chair is tflink. Information about MeetBot at http://wiki.debian.org/MeetBot. 15:02:00 Useful Commands: #action #agreed #halp #info #idea #link #topic. 15:02:06 #meetingname fedora-qa 15:02:06 The meeting name has been set to 'fedora-qa' 15:02:13 #topic Roll Call 15:02:17 #chair kparal 15:02:17 Current chairs: kparal tflink 15:02:33 * Martix is here 15:02:34 * pschindl is here 15:02:43 * satellit listening 15:02:45 oh, so it's here again 15:03:07 kparal: the meeting? Did I start in the wrong channel? 15:03:07 * mkrizek is here 15:03:08 here 15:03:11 * kparal is confused by channel changes 15:03:28 * spoore is listening...or trying to..may have to read log later 15:03:31 tflink: I don't really know, sometimes it's here and sometimes it's in fedora-qa 15:03:43 maybe blocker bug meetings are in #fedora-qa? I don't know 15:04:00 * Viking-Ice runs for a cup of coffee 15:04:18 * kparal thinks #fedora-meeting is better anyway 15:04:28 kparal: only blocker one 15:04:29 kparal: I think it's mostly in here. the blocker review meeting is in fedora-qa, though 15:04:38 * jskladan hides in the shadows 15:04:59 * kparal kicks jskladan 15:05:06 * jreznik is here 15:05:40 well, it sounds like most everyone is here, let's get started 15:06:16 #topic Agenda 15:06:28 #info Previous Meeting Follow-up 15:06:41 #info Release Criteria Proposals 15:06:59 #info F18 Beta Status 15:07:13 #info F18 Beta Mini Blocker Review 15:07:22 #info Open Floor 15:07:36 #topic Previous Meeting Follow-Up 15:08:10 "adamw to consider revisions to 'kickstart delivery method' criterion" - not yet done 15:08:30 at least I don't think it was done - did I miss a thread somewhere? 15:09:01 I haven't seen it either 15:09:49 neither has I 15:09:52 adamw: we are looking at you 15:09:52 ok, we can just put it down again for next week unless someone else wants to take it 15:10:09 Martix: he's on vacation today 15:10:22 adamw to consider revisions to 'kickstart delivery method' criterion 15:10:29 #action adamw to consider revisions to 'kickstart delivery method' criterion 15:10:35 tflink: I know, but adamw is also responding on #fedora-qa ;-) 15:10:44 tflink to ask other interested parties (anaconda team,fesco...) to look over the beta criteria and see if there's anything they feel should be dialled down 15:10:56 aand fail on my part 15:11:20 I wrote the email as a draft and forgot to actually send it out 15:11:42 I'll make sure it's updated with the most recent threads on test@ and send it out today 15:11:55 #action tflink to ask other interested parties (anaconda team,fesco...) to look over the beta criteria and see if there's anything they feel should be dialled down 15:12:20 I do believe that's all the things to follow up on 15:12:27 did I miss anything? 15:12:58 * tflink takes that as a no 15:13:13 well arguably anything of that stuff to be dialed down should not take effect until next release cycle 15:13:37 Viking-Ice: I see your point but that seems a bit harsh since we've been changing a bunch of stuff 15:14:09 Martix: i'm not here! 15:14:20 zombies talking 15:14:35 adamw: alright 15:15:05 tflink, it's one thing adjusting the criteria for dropped functionality and completely another thing to tone it down to cater to bugs that wont be fixed in time 15:16:03 Viking-Ice: if we write and attempt to enforce unreasonable release requirements, we're going to be on the path towards irrelevency, I think 15:16:14 as things stand now we have ca 25 bugs that are filed against anaconda that are either proposed blocker bugs or blocker bugs and adjusting the criteria does not fix the sorry state the installer is in 15:16:37 * tflink is of the opinion that it's a game of compromise 15:17:25 the not-here zombie notes that this is a complete side alley since we actually have no proposals to weaken any criteria. 15:17:48 and to me delaying the release to have these fixed ( without altering our criteria ) is better then adjust the criteria to meet some release date which we have never been able to meet anyway 15:17:55 when do you realise that we should drop newUI? and revert to last commit before newUI merge into Anaconda master :-P 15:18:08 it's too late in the game to drop it 15:18:14 I think we're getting really far off into the weeds here 15:18:22 which means we only slip from here on 15:18:31 and to me it's perfectly fine to slip 15:18:41 * tflink apologizes for the delay, didn't realize he would be leading until ~ 15 minutes before the meeting 15:18:45 12/25 release date workforme 15:18:51 #topic Release Criteria Proposals 15:19:00 worst case scenario santa deliver Fedora this Christmas ;) 15:19:03 #undo 15:19:03 Removing item from minutes: 15:19:13 #topic Upgrade Release Criterion Proposal 15:19:21 The last proposal I'm seeing is: 15:19:23 For each one of the release-blocking package sets ('minimal', and the package sets for each one of the release-blocking desktops), it must be possible to successfully complete an upgrade from a fully updated installation of the previous stable Fedora release with that package set installed, using any officially recommended upgrade mechanism. The upgraded system must meet all release criteria 15:19:35 that one would be for final 15:19:53 nvm, that's beta 15:20:03 the only difference is swapping any/all 15:20:15 * kparal acks 15:20:43 ack 15:20:49 "setenforce 0 && yum distro-sync" would be officially recommended ;-) 15:21:24 proposed #agreed QA accepts the criteria revision posted at xx:19 for beta 15:21:31 ack 15:21:38 Martix: you're not helping, we don't decide the recommended upgrade methods 15:22:13 tflink: just sidenote 15:22:27 sounds like we're pretty much agreed 15:22:35 #agreed QA accepts the criteria revision posted at xx:19 for beta 15:22:44 and for formality/boilerplate ... 15:22:50 Proposed final criterion: 15:23:08 For each one of the release-blocking package sets ('minimal', and the package sets for each one of the release-blocking desktops), it must be possible to successfully complete an upgrade from a fully updated installation of the previous stable Fedora release with that package set installed, using all officially recommended upgrade mechanisms. The upgraded system must meet all release criteria. 15:23:35 proposed #agreed QA accepts the proposed upgrade criterion listed at XX:23 for F18 Final 15:24:16 ack 15:24:22 ack 15:24:50 ack 15:25:10 #agreed QA accepts the proposed upgrade criterion listed at XX:23 for F18 Final 15:25:27 I think that was all of the changes since last week 15:25:39 unless I'm missing one in the partitioning thread 15:26:59 #topic F18 Beta Status 15:27:30 #info F18 Beta Freeze Entrance Readiness Meeting today @ 17:00 UTC 15:28:00 so the upgrade tool is still nowhere to be seen 15:28:09 yup so not freeze ready 15:29:00 * kparal wasn't exactly implying that 15:29:00 what are our reasons for saying that we don't think beta is ready for freeze (assuming that's pretty much the consensus here)? 15:29:47 the two that I can think of is the number of anaconda bugs around partitioning and the lack of a release for the upgrade tool 15:29:54 yuĆ° 15:29:58 mean yup 15:29:59 Is LVM, LUKS and RAID required for Beta? If not, purportedly in Beta TC2 those aren't available. 15:30:14 cmurf: I think that was put off to final 15:30:15 if they aren't they should be 15:30:20 but I'm not 100% sure 15:30:33 not-here zombie pop-up: we did not entirely decide it 15:30:39 Creating encrypted partitions is in Beta 15:30:45 we agreed that the criteria put into place last week were the *minimum* we needed 15:31:09 raid is also mentioned in Beta criteria (still) 15:31:28 oh yeah, we have an explicit criterion for raid 15:31:29 so that's clear 15:31:31 did I miss a discussion around the partitioning criteria? 15:31:32 lvm is the grey area. 15:31:37 this things must be working if upgrade is required to work 15:31:45 this/these 15:32:07 we know that there are bugs. I'm not sure that means we can't enter Beta freeze 15:32:08 oh, that's a wrinkle that I hadn't thought about 15:32:17 F17 default install used LVM 15:32:24 In beta release, LVM is only mentioned for the installer rescue mode so creating them doesn't appear required. For beta. 15:32:32 but we definitely still haven't seen the upgrade tool 15:32:49 how well is upgrade going to work w/ LVM? 15:32:54 tflink: my understanding is that there won't be LVM by default. Either it's ext4 on separate partitions, or btrfs plus subvols. 15:33:18 tflink: I don't know, but I'd like to think that's expected to work or it's a problem. 15:33:20 cmurf: for F18+, sure. I'm concerned about upgrades from F17 15:33:36 so, the things that we're concerned about are: 15:33:42 yes but the upgrade path must support LVM since LVM was the default before F18 15:33:55 1. We aren't aware of a release for the upgrade tool 15:34:34 the other one was mostly RAID, no? 15:35:08 I never tested that 15:35:34 beta release criteria 11: installer must be able to create and install to software, hardware or BIOS RAID-0, RAID-1 or RAID-5, except for /boot 15:35:52 I'm not seeing it in the ui 15:36:01 kparal: yeah, neither have I. looks like I know what I'm doing in the next hour or so :) 15:36:02 * satellit note "disks" on live desktop CD cannot reformat a previous f18 install to HD - anaconda cannot do this from Beta TC2 netinstall either (just tested it) 15:36:05 but i could be confused 15:36:20 iirc it's not expressed as RAID exactly, but there are checkboxes for 'redundancy' or something like that. it's in custom part. 15:36:42 satellit: yeah, I think that one's known. there was a new anaconda build on friday but it had more issues and a new TC wasn't built 15:36:54 ok 15:37:48 is there any reason to be concerned about the functionality of the partitioning UI (outside of RAID) to the point that freeze might not be wise? 15:38:23 is the intention of beta release criteria 11 to mean that the creation of software RAID 5 is required for / or /home? 15:38:58 cmurf: I believe so, yes 15:39:50 interesting. 15:40:02 ok about freeze, i felt that alpha freeze came too soon expecially for anaconda. 15:40:04 ok, wwoods seems to be still working on fedupg - that means no release 15:40:15 is there an opinion from the anaconda team on freeze status for beta? 15:40:21 cmurf: yep and that's the reason for this special meeting 15:40:22 is there an interest in coming up with a recommendation from QA for freeze readiness? 15:40:51 tflink: it would be great if qa could do it 15:40:59 jreznik, that and the the share number of bugs against Anaconda that either are blocking or proposed as blocking should be sufficiant to raise the alarms and slip ;) 15:41:42 I believe QA should get a chance to play with the upgrade tool before entering the freeze 15:41:49 that would be my proposal 15:41:50 jreznik: yes i know that, my question is if the anaconda team has an opinion on freeze causing them more work that's unnecessary/not helpful 15:42:00 not-here zombie is also for slipping the freeze, on fedup grounds. 15:42:43 kparal: not "play" but it should be released as a real release - packaged etc. 15:42:43 ok, sounds like we're pretty much pro-freeze slip 15:42:48 * tflink got a phone call 15:42:57 we are still waiting for fedup, we should slip freeze and poke Anaconda and fedup developers 15:43:33 proposed #agreed QA Recommends slipping of freeze at this time due to no currently testable upgrade tool for F18 15:43:34 Martix: already doing - the poking stuff 15:43:53 We must be able to evaluate the readiness of the upgrade tool before we freeze and to do so it must be present :) 15:43:54 ack 15:43:56 ack 15:44:30 * tflink wants more than 2 acks before doing the #agreed 15:44:37 ack 15:44:37 ack 15:44:42 ack 15:45:29 #agreed QA Recommends slipping of freeze at this time due to no currently testable upgrade tool for F18 15:45:43 jreznik: we should start kicking in their arses! :-) 15:46:05 is qa going to talk also about part. requirements or thinks missing upgrade tool is enough? 15:46:18 Martix, please refrain from using language like that. 15:46:28 jwb: ok, my appologize 15:46:29 Martix: I don't think that will make things more likely to go a way you're happy with. 15:46:37 Martix: no, please - what we need is to explain what we need/require 15:47:33 any thoughts on the partitioning requirements? 15:47:48 jreznik: ok: testable fedup, abbility to remove partitions in Anaconda, abbility to upgrade on LVM/LUKS/RAID 15:48:05 ability to install w/ RAID 15:48:14 abbility to create LUKS partitions 15:48:38 but I can't remember off the top of my head whether that funtionality already exists 15:49:16 and I'm not convinced that the current issue of anaconda not doing well at removing existing partitions is enought to justify slipping freeze 15:49:44 so other than the missing upgrade tool (which I do think is enough to justify slipping freeze, personally) 15:49:45 tflink: so could you guys please retest? if functionality exists before mtg? or maybe better to ask anaconda guys directly :) 15:49:58 jreznik: I'm planning to do so 15:50:42 the potentially problematic areas (pending re-test) as I see them are: 15:50:46 LUKS and RAID 15:51:13 fedup should be testable by the enf of the week 15:51:32 It's a bit awkward having RAID in custom partitioning, but perhaps that's a squawk for F19. RAID != partitioning. 15:52:12 it belongs in the advanced storage spoke 15:52:14 proposed #agreed outside of the upgrade tool, install w/ RAID and/or LUKS is another potential issue that needs re-testing 15:52:34 ack 15:52:37 * kparal is testing LUKS now 15:53:14 * tflink will test RAID right after the meeting 15:53:18 jreznik: deja vu 15:53:35 * tflink demands more ack/nak/patch !!! 15:53:36 ack 15:53:42 * satellit yum installed gparted to desktop live added msdos partition table will retry TC2 Netinstall on the HD 15:53:58 i'm testing it now and my biggest issue is UI confusion honestly 15:54:00 luks fails, it doesn't ask for password and creates a standard unencrypted partition 15:54:03 it = RAID 15:54:09 at least it seems so 15:54:39 keep in mind that we aren't asking everything to _work_ 100% for freeze entrance 15:54:52 yep 15:54:52 just that the functionality is testable and somewhat present 15:54:55 sure. is the testing to be based on TC2? 15:55:13 so if LUKS isn't quite working but at least somewhat works - it's OK for freeze entrance 15:55:30 same with RAID 15:56:02 * satellit looks like it worked (gparted on live desktop) 15:56:32 so ... any more votes on the proposal? 15:56:34 tflink: ack 15:56:48 ack 15:57:07 proposed #agreed outside of the upgrade tool, install w/ RAID and/or LUKS is another potential issue that needs re-testing. We will retest these things before the freeze entrance readiness meeting. 15:57:22 since the change isn't big, I assume that all the acks hold 15:57:28 #agreed outside of the upgrade tool, install w/ RAID and/or LUKS is another potential issue that needs re-testing. We will retest these things before the freeze entrance readiness meeting. 15:57:37 well, does "it doesn't ask for password and creates a standard unencrypted partition" - means it somehow works or not at all? ;-) 15:57:57 jreznik: do we know if the code exists? 15:58:02 * kparal just reported https://bugzilla.redhat.com/show_bug.cgi?id=864120, logs will follow shortly 15:58:13 jreznik: not at all, currently, it seems 15:58:23 kparal: thx 15:59:37 anything else about beta? 16:00:09 if not, I propose that we skip the blocker review for today so that we can get a bit more testing done before the meeting (in ~ 1 hour) 16:00:19 ack 16:01:29 it's interesting to see people trail off as meetings go on :) 16:01:46 anyhow, I assume that there are no objections 16:01:48 I actually would like us to go through the proposed blocker bugs against anaconda 16:02:10 Viking-Ice: I don't disagree but it's difficult to do blocker review and RAID test @ the same time 16:02:11 Viking-Ice: good idea, to have a better overview before the meeting 16:02:22 but yeah, manpower 16:02:24 Viking-Ice: ack 16:02:27 jreznik: you don't get it both ways - either testing of blocker review 16:02:33 s/of/or 16:02:57 unless someone else is going to do lead the blocker review or do the RAID testing 16:03:00 maybe if someone will be willing to go through the testing and the rest could do blocker review 16:03:05 I can't do both at the same time 16:03:13 is the RAID code supposed to be in place and working in Anaconda ? 16:03:19 tflink: not asking you to do both :) you're already the hero! 16:03:26 Viking-Ice: I have no idea, that's what I wanted to find out 16:03:32 Viking-Ice: asking on #anaconda right now 16:03:34 i/we/other pronoun 16:03:58 "raid support has been in since the first post-alpha tree" 16:04:31 ah so it's just broken ;) 16:04:54 jreznik: what about LUKS? 16:04:57 maybe, I just don't think anyone's tested it yet 16:04:59 what's the time frame for TC3? 16:05:08 Martix: patches were posted on thursday 16:05:18 cmurf: when we get another anaconda build, I think 16:05:36 well, ok - let's give qa time to test if raid is there, I'll go through the anaconda list bugs to get an overview for mtg 16:05:50 Martix: patches posted for luks 16:06:02 great 16:06:40 RAID is in beta TC2 16:07:33 It's md raid for all file systems except btrfs which does its own raid0/1/10 but not 5 (yet) and there isn't an option to use md raid 5 for btrfs. 16:07:40 cmurf: it works, I assume? 16:07:52 testing 16:08:02 cmurf: I don't believe that there is GUI support for btrfs yet 16:08:07 but I could be wrong 16:08:11 there is support for btrfs 16:08:30 it even uses subvols for root and home 16:09:35 if i use a single disk only, anaconda crashes when changing Device Type to RAID. So I think someting is hooked up to cause that. 16:09:50 cmurf: are you testing w/ multiple disks? 16:10:15 about to but figured i'd see what happens with one first 16:11:13 do we still have enough people to do blocker review, then? 16:11:24 ok so the parameters are two disks, and RAID 1 for everything 16:12:04 I take that as a no, we don't have enough people 16:12:15 we have 16:12:16 UI is present 16:12:25 but i get anaconda crashes 16:12:45 me too 16:13:39 so i think those need to be isolated, see if there are bugs already filed, if not file bugs because these would appear to be beta blocker bugs 16:14:07 but not freeze inhibiting bugs 16:14:13 either way, it looks like we have no real grounds to block freeze for RAID 16:14:19 agreed 16:14:21 and not much for LUKS 16:14:26 agreed 16:14:28 ui is present 16:14:30 cmurf: you didn't heard about cat-o-9 rule proposed by tflink? 16:14:38 ? 16:14:43 Martix: that was for during blocker review meetings 16:14:53 and specifically aimed at you :-P 16:14:57 which is right now ;-) 16:15:02 it is? 16:15:15 what is the cat-o-9 rule 16:15:56 cmurf: anyone who makes huge changes to the blocker list in the middle of a review meeting gets flogged :) 16:16:11 Martix: good that you remember 16:16:24 tflink: that required a rule? 16:16:36 cmurf: apparently, yes 16:16:44 sad 16:17:16 anyhow, since it looks like enough testing has been done for RAID and LUKS for pre-freeze, shall we go through the blocker bugs quickly? 16:18:06 tflink: ok, this means - luks/raid support is on-going, no need to block freeze but upgrades... do I understand it correctly? 16:18:36 jreznik: yeah, that's what it looks like right now 16:18:45 tflink: thanks guys! 16:19:00 but I think we're pretty firm on not entering freeze w/o a testable upgrade tool 16:19:01 tflink, we probably should move the blocker bug process into QA 16:19:06 * jreznik is ok with quick blocker bugs review now 16:19:23 tflink: so if you're talking beta blocker, the RAID bugs will eventually be blockers. I'm not seeing bugs file for the bugs I'm encountering. 16:19:24 jreznik: make sure that fedup release in the end of week will support existing LVM/LUKS/RAID setups 16:19:25 Viking-Ice: not sure I understand what you mean 16:20:05 cmurf: if the code is present and testable, that should be enough for freeze entrance - we aren't looking to have a beta-ready release before we enter freeze 16:20:39 "shall we go through the blocker bugs quickly" are you referring to beta blocking, or freeze? 16:21:02 cmurf: just the currently proposed blockers 16:21:09 goti t 16:21:23 it'll take me a while to write these up, need to reproduce them consistently 16:21:54 I really don't think we're going to get through the proposed blockers in 40 minutes 16:22:19 just anaconda 16:22:41 and I fail to see much of a point in doing this just for the freeze-entrance meeting 16:22:46 only 15-16 bugs :-) 16:22:48 true 16:23:14 tflink, I was proposing moving the blocker review process to the QA channel ( as opposed to be doing it here ) 16:23:32 would anyone mind telling me where anaconda logs are now kept? they're not in ~ or /var/log when booted off netinstall 16:23:40 and if we start with the Anaconda bugs we might be done with them before the topic comes up at the fesco meeting 16:23:49 cmurf: /tmp 16:23:51 cmurf, /tmp 16:24:12 cmurf: the logs are persisted on shutdown of the installer - if you get a crash, they won't be written to disk 16:24:14 oops that's not new. 16:24:20 I assume that's what you were asking 16:24:27 at least I don't think they will 16:24:33 recurring temporary confusion 16:24:50 the journal should pick it up 16:24:55 OK, lets adjurn and regroup in #fedora-qa for blocker review awesome fun happy time 16:25:26 #info Blocker Review will start immediately after this meeting in #fedora-qa 16:25:37 #topic Open Floor 16:25:48 Is there anything else that absolutely needs to be brought up now? 16:25:56 not from me 16:26:21 Then I think that we're done here for now 16:26:32 Thanks for coming, everyone! 16:26:35 #endmeeting