QA/Meetings/20130107

From FedoraProject

Jump to: navigation, search

Contents

Attendees

  • adamw (205)
  • tflink (195)
  • Viking-Ice (89)
  • kparal (68)
  • Martix (54)
  • nirik (31)
  • jreznik (25)
  • dan408 (22)
  • jreznik_n9 (14)
  • rbergeron (9)
  • maxamillion (7)
  • zodbot (6)
  • Southern_Gentlem (2)
  • jskladan (1)
  • satellit (1)
  • vhumpa (1)

Agenda

  • Previous meeting follow-up
  • Fedora 18 Final blocker review
  • Fedora 18 Final status / planning
  • Open floor

Previous meeting follow-up

  • viking-ice to let docs team know about advanced storage for release notes - this was done, install guide points advanced storage users to kickstart

Fedora 18 Final blocker review

  • #892621 was accepted as a blocker per workable partition layout criterion
  • #892269 was rejected as a blocker as it could not be fixed in a safe way in short enough time
  • #892188 was rejected as a blocker and NTH: didn't meet criteria, too dangerous to fix
  • #892669 was rejected as a blocker due to restricted impact, accepted as NTH
  • #892046 was rejected as a blocker for being an unreasonable operation, accepted as NTH
  • #892196 was rejected as a blocker due to restricted impact, accepted as NTH
  • #875291 was rejected as a blocker as not severe enough, accepted as NTH
  • #892120 was accepted as NTH: safe and useful fix
  • #886685 was rejected as NTH for lack of impact on primary arches

Fedora 18 Final status / planning

Open floor

N/A

Action items

N/A

IRC Log

adamw #startmeeting Fedora QA meeting 16:01
zodbot Meeting started Mon Jan 7 16:01:14 2013 UTC. The chair is adamw. Information about MeetBot at http://wiki.debian.org/MeetBot. 16:01
zodbot Useful Commands: #action #agreed #halp #info #idea #link #topic. 16:01
adamw #meetingname fedora-qa 16:01
zodbot The meeting name has been set to 'fedora-qa' 16:01
adamw #topic roll call 16:01
* Martix . 16:01
* tflink is present 16:01
* jskladan tips his hat 16:01
* kparal tips jskladan's hat 16:02
* jreznik is here 16:02
* nirik is lurking 16:03
jreznik (but has to leave earlier today... will be back later, real life...) 16:03
* maxamillion is here 16:03
* vhumpa lurking 16:04
maxamillion actually ... that's a fib, going to refill my coffee cup then I'll actually be here 16:04
adamw morning everyone 16:04
* satellit listening 16:04
adamw #topic previous meeting follow-up 16:05
adamw so I see one action item from the last meeting way back on 12-17 16:06
adamw "viking-ice to let docs team know about advanced storage for release notes" 16:06
adamw do we have a viking? 16:06
tflink he was around earlier 16:07
adamw lemme check docs archive 16:08
adamw i don't see anything in the archive, so we'd better check back with him alter 16:09
adamw #info "viking-ice to let docs team know about advanced storage for release notes" - viking-ice isn't around and we don't see anything in the docs@ archives, better check in with him later 16:09
adamw alrighty, onto the main course 16:09
adamw #topic Fedora 18 Final status and blocker review 16:10
adamw let's just go straight into blocker review, if tflink's ready? 16:10
adamw #chair tflink kparal maxamillion 16:10
zodbot Current chairs: adamw kparal maxamillion tflink 16:10
tflink yep 16:10
jreznik if we could go top important to less imporant way - I have to leave in 30 minutes today :( 16:10
maxamillion oh jeebus, why am I a chair? 16:11
tflink maxamillion: you're leading the blocker review today - didn't anyone tell you? 16:11
tflink  :-D 16:11
adamw maxamillion: mainly because I like typing maxamillion 16:11
maxamillion no .. :X 16:11
adamw and throwing chairs 16:11
maxamillion adamw: awww, something about that feels kind 16:11
tflink jreznik: define top issues - the list that adamw started in #anaconda? 16:12
jreznik tflink: yep 16:12
* jreznik has sent similar list before :) 16:12
adamw let's knock off the obvious blocker first 16:12
tflink OK, these are going to be quite out of order compared to the webapp then 16:12
tflink #topic (892621) Anaconda FC18-TC4 does not present BIOS RAID as available storage 16:12
tflink #link https://bugzilla.redhat.com/show_bug.cgi?id=892621 16:13
tflink #info Proposed Blocker, anaconda, NEW 16:13
tflink jreznik: you did? I don't remember seeing that email 16:13
jreznik tflink: #anaconda earlier today, doesn't matter right now :) 16:13
jreznik Jes raised it today 16:14
adamw seems like an obvious +1, sadly 16:14
adamw wish i'd tested earlier and caught this at tc4, but was too busy with other bugs :( 16:14
jreznik seems like regression between tc3 and tc4 16:14
jreznik well it's pretty serious one, I have to say +1 blocker 16:15
adamw my only caveat is we only have jes' case, but for now, +1 16:15
tflink proposed #agreed 892621 - AcceptedBlocker - Violates the following F18 final release 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" 16:15
jreznik adamw: you caught it too, aren't you? 16:15
Martix ack 16:15
adamw jreznik: no, i haven't tested yet 16:16
adamw jreznik: i have to do bios raid testing on my main desktop so it's kind of a pain and stops me being able to do much else while i'm doing it 16:16
adamw ack 16:16
kparal ack 16:16
jreznik adamw: I see I wish, sorry 16:16
jreznik ack 16:16
tflink #agreed 892621 - AcceptedBlocker - Violates the following F18 final release 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" 16:16
tflink #topic (892494) deleting existing LV doesn't free space to allow creation of new LV 16:16
tflink #link https://bugzilla.redhat.com/show_bug.cgi?id=892494 16:17
tflink #info Proposed Blocker, anaconda, NEW 16:17
adamw i'm fairly sure this is essentially the same bug as https://bugzilla.redhat.com/show_bug.cgi?id=892269 16:17
adamw doesn't really matter whether you shrink or delete an existing LV, the problem is with 'free space' calculation inside a container 16:17
kparal might be a dupe. your repro was too difficult, mine was simple :) 16:18
jreznik looks like 16:18
jreznik but with same result and same issue behind 16:18
kparal I think it doesn't matter much, anaconda guys can dupe if necessary 16:18
adamw kparal: reducing the size of an LV is about as easy as deleting it, really. just change the size in the 'properties' bit. 16:19
kparal do we want to know it now? 16:19
tflink sounds like we're +1, though? 16:19
adamw kparal: can you confirm they're dupes with the test i mentioned? create the new LV with a specific size and check it works? 16:19
kparal adamw: I can, sure. right now? 16:20
adamw it'd help. 16:20
adamw i guess i can too. 16:20
* kparal starting VM 16:20
adamw tflink: for me this is right on the blocker/nth fence 16:20
adamw you *can* deal with it by specifying a size 16:20
adamw it does suck pretty bad though 16:20
kparal adamw: so should I resize the existing LV, or delete the existing one and create a new one? 16:21
adamw kparal: don't bother, i just confirmed it. they're dupes. 16:21
kparal right now I have the existing layout - /boot and LV / + LV swap 16:21
adamw kparal: if you try shrinking / instead of deleting it, you'll see it behaves just the same as in your video 16:23
adamw no 'free space' is created, and if you create a new LV and don't specify a size, it'll come up as 900kB 16:23
adamw but if you specify a size, it'll 'work' 16:23
kparal I deleted / and created a new one with 5 GB. it succeeded, even though I had 1 MB of free space supposedly 16:23
* Viking-Ice here 16:23
adamw right. 16:24
adamw exactly the same behaviour. i've marked this as a dupe of 892269 and edited the summary slightly. 16:24
kparal that's really stupid bug 16:24
jreznik it is 16:25
adamw yeah. like i said i'm right on the edge of blocker/nth. 16:25
kparal you have to count the remaining size in hand 16:25
adamw in the long run we probably need anaconda to track 'unpartitioned space' and 'free space within each existing container' separately, i think 16:26
kparal new interface! 16:26
adamw a single 'free space' counter doesn't really do the job 16:26
kparal NewNewUI 16:27
Martix yeah! 16:27
adamw =) 16:27
jreznik nooo, please! it's not a joke! 16:27
adamw morning viking, dan 16:27
dan408 hi 16:27
jreznik well, so where we are with this one? 16:27
dan408 im not really here 16:27
dan408 im just lurking 16:27
Martix jreznik: are you sure? 16:27
adamw for f18 there should be some kind of workaround possible, i guess 16:27
adamw jreznik: no-one but me seems to be voting 16:27
dan408 adamw: i vote +1 for all 16:27
kparal if it wasn't January already, I'd be clearly +1 16:27
Martix +1 blocker 16:27
tflink +1 16:28
kparal I'm not so sure now 16:28
* jreznik is with kparal 16:28
* Viking-Ice points adamw to https://bugzilla.redhat.com/show_bug.cgi?id=885808#c1 16:28
dan408 which bug are you all discussing? 16:28
tflink dan408: see topic 16:28
Martix make your minds :-) 16:28
Martix dan408: see topic 16:28
Martix tflink: I read slower then I type 16:29
kparal jreznik: there can be only one vote fuzzificator here 16:29
adamw tflink: actually can you change topic to 892269? 16:29
kparal and that's me 16:29
adamw since i duped this one off 16:29
* nirik reads up on it. 16:29
dan408 the whole custom partitioning thing needs to be reworked 16:29
tflink #info 892394 has been marked as a duplicate of 892269 which is also proposed as a blocker. Moving discussion to that bug 16:30
tflink #topic (892269) Free space calculation interferes with creation and resizing of LV within existing VG after shrinking existing LV 16:30
tflink #link https://bugzilla.redhat.com/show_bug.cgi?id=892269 16:30
tflink #info Proposed Blocker, anaconda, NEW 16:30
Martix let ask somebody from Anaconda, if they know how to fix it soon 16:30
kparal nirik: I have a nice shiny video in 892394 16:30
adamw dan408: yeah, that's not happening for f18. let's keep the discussion practical. 16:30
dan408 no i mean 16:30
dan408 there are 3 bugs on partitioning, dont you think they might be somewhat related? 16:31
nirik I'm -1 blocker, +1 NTH/commonbugs/releasenote. 16:31
Martix adamw: I didn't see planned Anaconda features for F19, do you? 16:31
tflink sounds like we're +3/-3 16:31
kparal I'm +0 16:31
tflink +3/-2 16:31
* jreznik is weak -1 to make it harder 16:31
Viking-Ice +1 16:31
tflink +4/-1.5 16:31
kparal  :D 16:31
Martix come on :-D 16:31
dan408 +1 blocker 16:32
jreznik but would like to hear more from anaconda 16:32
tflink +5/-1.5 16:32
Martix jreznik: +1 16:32
adamw <dlehman> for the lvm thing any potential fix would probably need pretty wide testing 16:32
tflink so we get down to practicality 16:32
kparal adamw: that means we can't have it as NTH either, if we refuse it as a blocker on that ground 16:32
tflink we could do a smoke build with an anaconda scratch build or updates.img 16:33
adamw kparal: yeah, pretty much 16:33
adamw well, we could accept it as nth but not take the fix. :) 16:33
jreznik what would be the definition of wide testing? 16:33
jreznik go through the lvm test cases? 16:33
Martix adamw: so why we are discussing it? 16:33
tflink if the only reason we wouldn't take it as a blocker is the time until fix or risk, lets take it as a blocker for now and re-evaluate when we have a more concrete idea of the actual risk for more slippage 16:33
kparal does that mean "have kparal play with it for an hour"? 16:34
adamw <dlehman> basically don't cap specified max for new mountpoints based on free space 16:34
adamw no, definitely not going to try to make free space calculation any more complex at this point 16:34
adamw <adamw> that wouldn't solve the 'user doesn't enter a size' case, would it? 16:34
adamw <dlehman> it would not 16:34
adamw <adamw> well, i suppose they could edit the size, at least 16:34
adamw and that sounds like a worryingly impactful change. 16:34
Martix tflink: +1 16:34
adamw Martix: we have to decide on blocker status. 16:34
Viking-Ice we already have 16:34
Viking-Ice based on my account it's an blocker 16:34
jreznik tflink: if we take it now, how difficult would it be to convince qa to fudge :) 16:34
tflink unless votes change, yes 16:34
adamw please do take into account the quotes from dlehman. 16:35
adamw i am changing to -1 on that basis as i think the proposed 'fix' is problematic and just as likely to cause worse problems. 16:35
tflink jreznik: depends on the actual risk 16:35
adamw if dlehman thinks that's the best 'fix' possible i'd rather just document the problem. 16:35
nirik what criteria are the folks voting +1 going by? 16:35
dan408 adamw: thats why I said what i did earlier 16:35
kparal adamw: what would dlehman vote? 16:35
* jreznik is not happy with this bug, but what dlehman said is quite horrifying... 16:35
dan408 kparal: wwjd? 16:35
kparal dan408: ? 16:36
dan408 nm 16:36
tflink yeah, I'm also not convinced this is a good idea - +1 in principle but not sure it's worth it 16:36
dan408 there are what 3 custom partitioning bugs that are proposed blocking right? 16:36
tflink nirik: "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" 16:36
adamw dan408: there are basically two bugs. 16:36
tflink dan408: 2 now, there was a dupe 16:36
adamw this one, and one to do with multiple-device btrfs containers. they're not related. 16:36
nirik seems like a streach... since you can get a workable layout 16:36
dan408 adamw: you're missing one 16:36
Viking-Ice nirik, If anaconda is not ready for release it's not ready for release and we should delay if it breaks our already existing criteria 16:36
dan408 .bug 875291 16:37
zodbot dan408: Bug 875291 custom partitioning loses focus - https://bugzilla.redhat.com/show_bug.cgi?id=875291 16:37
tflink nirik: that criterion implies the ability to resize. there are beta criterion that specify resizability 16:37
Viking-Ice nirik, sad but true 16:37
dan408 3 16:37
nirik Viking-Ice: yes, I was asking what specific critera. 16:37
Martix *ding* 20 minutes passed for this bug 16:37
dan408 i say group them together and try and get them fixed this week if possible 16:37
tflink actually, I'm wrong. resize-ability isn't specifically called out 16:37
adamw yeah, resizing is not key to the bug. 16:38
adamw it affects deleting LVs too. 16:38
* kparal recommends to watch #anaconda 16:38
dan408 kparal: one day 16:38
kparal dan408: I mean right now 16:38
adamw Viking-Ice: at some point we have to take practicalities into consideration. we can't start ripping up the custom part code for f18 now. if the only practical 'fix' is a band-aid which doesn't really fix the problem and could easily create other problems, i do not think we should poke it. 16:38
* jreznik is now more -1/document and has to leave, will be watching discussion from cell phone, sorry 16:38
nirik It doesn't crash right? just gives you the too small space to install ? 16:39
dan408 kparal: okay. 16:39
Viking-Ice adamw, I full well understand the risk at poking at it 16:39
adamw yeah, it doesn't crash 16:39
adamw you do at least have the opportunity to keep trying till you hit on the method that works 16:39
tflink either way, I'm -1 NTH - this is too much risk for an NTH bug 16:39
kparal nirik: but if you don't know about it, you might not be able to create your partitions 16:39
adamw i like the idea of voting +1/-1, but i follow your reasoning :) 16:39
* nirik is still +1 NTH, if the fix somehow proves simple we could take it. 16:39
Viking-Ice I'm still +1/-1 and we either block or not based on the risk 16:40
Martix I withdraw my vote 16:40
tflink same here, we can re-evaluate blocker status later if need be 16:40
kparal dlehman went silent. I think we should go -1 blocker, and evaluate nth vote based on the patch, if available 16:41
tflink I've lost track of the votes, though. Can people re-state their votes? 16:41
Viking-Ice +1 16:41
tflink +1/-1 16:41
adamw -1 16:41
Martix let's discuss it on next mtg after Anaconda devs reevaluate benefits/risks 16:41
adamw Martix: we really don't have that much time. 16:41
Viking-Ice yup 16:41
jreznik_n9 -1 16:41
tflink +2/-2 total so far 16:42
Viking-Ice adamw, well jes bug kinda is a blocker no ;) 16:42
adamw i may change to +1 if a more useful plausible fix showed up. 16:42
adamw Viking-Ice: sure, dlehman already has a fix for that, though. 16:42
Martix #needinfo 16:42
tflink so punt or re-propose if a different fix showed up? 16:42
adamw we 16:42
Viking-Ice just count the votes 16:42
adamw we're missing a few votes 16:42
tflink I don't like the idea of punting 16:42
dan408 punt, but i'd like to say these 3 bugs should be grouped together 16:42
tflink I restarted the count 16:43
kparal -1 blocker, nth after patch available 16:43
tflink it got too complicated 16:43
nirik -1/+1 16:43
tflink +2/-4 16:43
tflink +2/-4 blocker, +2/-2 NTH 16:43
dan408 +1 16:43
* maxamillion is torn 16:43
tflink +3/-4 blocker, +2/-2 NTH 16:43
* tflink sets timer for 2 minutes on votes - we need to move on 16:44
jreznik_n9 pls count dlehman too 16:44
tflink he voted? 16:44
kparal jreznik_n9: he didn't vote 16:44
Martix -1 blocker/+1 NTH 16:44
Viking-Ice jreznik_ 9 can he vote 16:44
tflink kparal: he did in #anaconda 16:44
adamw <dlehman> weak -1 blocker, +1 NTH 16:44
jreznik_n9 he voted 16:45
tflink +3/-6 blocker, +4/-2 NTH 16:45
Viking-Ice maintainers can only provide input not vote on their own bugs 16:45
Martix tflink: propose 16:45
Viking-Ice that's just stupit 16:45
Viking-Ice if they could 16:45
adamw why is it stupid? 16:45
kparal the maintainers have the best understanding of the risk 16:45
kparal it's completely valid 16:45
adamw it's not like they're going to vote -1 just to save themselves work. 16:45
Viking-Ice yes their input their vote no 16:45
Martix stick to the topic please 16:46
Martix keep this for open floor :-) 16:46
tflink proposed #agreed 892269 - RejectedBlocker AcceptedNTH - While this is a blocker in principle, the currently proposed fix was judged too risky to take this late in the release process. A tested fix would be considered past freeze if a less risky fix is proposed 16:46
tflink ack/nak/patch? 16:46
dan408 im off to $dayjob, will try to get on from there 16:46
Martix ack 16:46
jreznik_n9 ack 16:47
kparal ack 16:47
Viking-Ice hold on hows the count here 16:47
adamw ack 16:47
adamw <tflink> +3/-6 blocker, +4/-2 NTH 16:47
* nirik isn't sure that it actually meets any critera, but ok. 16:47
Viking-Ice dont we have -6 nth ? 16:47
adamw even if you don't count dlehman's vote, still majority for -1/+1. 16:47
tflink we do? 16:47
Viking-Ice tflink, this split count got me confused are we +4 16:48
Viking-Ice nth 16:48
Viking-Ice +3 blocker 16:48
kparal the counts are correct 16:48
Viking-Ice ack if nth 16:48
kparal green light, let's move 16:48
* jreznik_n9 is more 0 nth and smoke testing, if we have time 16:49
tflink #info Blocker Votes: (+1) tflink, Viking-Ice, dan408 (-1) adamw, dlehman, kparal, jreznik, nirik, Martix 16:49
tflink #info NTH Votes: (+1) nirik, adamw, jreznik, Martix, dlehman (-1) tflink, Viking-Ice 16:50
tflink did I screw up anyones votes? 16:50
adamw i didn't vote on NTH. 16:50
Viking-Ice yeah I though that 16:50
tflink #undo 16:51
zodbot Removing item from minutes: <MeetBot.items.Info object at 0x2a8a0d50> 16:51
* kparal is practically +1 nth 16:51
tflink #info NTH Votes: (+1) nirik, jreznik, Martix, dlehman, kparal (-1) tflink, Viking-Ice 16:51
kparal because we don't need to accept the fix 16:51
Viking-Ice it would be better to not pull this in as an nth from my pov instead of risk pulling it in if people are not going for blocker 16:51
tflink #agreed 892269 - RejectedBlocker AcceptedNTH - While this is a blocker in principle, the currently proposed fix was judged too risky to take this late in the release process. A tested fix would be considered past freeze if a less risky fix is proposed 16:51
tflink #topic (892188) anaconda in manual partitioning cannot 'reformat' previous / if previous /home is a subvol on the same btrfs partition 16:52
tflink #link https://bugzilla.redhat.com/show_bug.cgi?id=892188 16:52
tflink #info Proposed Blocker, anaconda, NEW 16:52
adamw this is basically notabug, i think. definitely -1/-1. 16:53
Viking-Ice -1/-1 16:53
tflink -3/-2 from the bug 16:53
jreznik_n9 -1/-1 16:53
adamw cmurf's comments are useful here - it kinda helps to understand how btrfs subvols work (which i really didn't until reading cmurf's notes) 16:54
tflink proposed #agreed 892188 - RejectedBlocker RejectedNTH - This is not a regression from F17 and it is possible to workaround by formatting outside the installer. Risk/reward ratio judged not enough to take a fix this late as NTH. 16:55
* nirik waits for bugzilla. 16:55
* Viking-Ice thought we did not "officially" support btrfs in anaconda in general 16:55
adamw patch 16:55
adamw it's not really about 'working around' it, it's just that this isn't a thing you should really do anyway. 16:55
Martix isnt this regression? 16:55
adamw Martix: as f17 had no btrfs UI at all, by definition, no. 16:55
Viking-Ice adamw, is that kinda notabug then? 16:55
Martix adamw: meant from previous tc 16:56
adamw Viking-Ice: cmurf and I think so but it'd be best to get confirmation from anaconda team before closing. 16:56
adamw Martix: the comment means 'from f17', not 'from previous tc' 16:56
tflink proposed #agreed 892188 - RejectedBlocker RejectedNTH - This is not a regression from F17 and this isn't something that you should be doing inside the installer anyways - reformatting of btrfs subvols should be done outside anaconda. Risk/reward ratio judged not enough to take a fix this late as NTH. 16:56
Martix ok 16:56
adamw still not really right. it doesn't make a lot of sense to reformat a btrfs subvol, given what it is. you just create and destroy them. 16:57
adamw well, anyway 16:57
adamw it's close enough 16:57
adamw ack 16:57
kparal ack 16:57
Viking-Ice ack 16:57
Martix ack 16:58
tflink #agreed 892188 - RejectedBlocker RejectedNTH - This is not a regression from F17 and this isn't something that you should be doing inside the installer anyways - reformatting of btrfs subvols should be done outside anaconda. Risk/reward ratio judged not enough to take a fix this late as NTH. 16:58
tflink I think those are all of the proposed blockers highlighted 16:58
tflink I assume that the idea is to finish going through the rest of them? 16:58
* tflink wasn't clear from before 16:59
adamw we should, yeah 16:59
tflink #topic (892669) slow NIC and local kickstart -> anaconda crash 16:59
tflink #link https://bugzilla.redhat.com/show_bug.cgi?id=892669 16:59
tflink #info Proposed Blocker, anaconda, NEW 16:59
* adamw not really sure on this one. 16:59
Viking-Ice -1/-1 17:00
nirik do we know what cards this would affect? 17:00
Viking-Ice I think this is highly unlikely scenario 17:00
kparal I just want to point out that we have a machine with slow NIC in our office, and it's brand new desktop with latest AMD processor and state of the art UEFI motherboard 17:00
tflink -1/+1 - seems too much of a corner case to block over right now 17:00
kparal so it's not that unlikely 17:00
nirik kparal: whats the net card/driver out of curiosity? 17:01
Viking-Ice kparal, I somehow picture nic from the last century 17:01
Viking-Ice swinging to -1/+1 17:01
kparal nirik: I can't tell you right now 17:01
tflink I was more referring to the odds of having both local ks on media w/o packages, slow nic 17:01
* nirik wonders if it's a bnx2. 17:01
adamw 'slow NIC' seems weirdly non-specific. is this not just as likely to be to do with the connection setup or router? 17:01
tflink workaround: put packages on same local disk 17:02
adamw it sounds like we really mean 'slow network setup'. 17:02
kparal adamw: no, all our machines are on the same LAN. I think it's really slow NIC 17:02
kparal the link address is very slow to appear 17:02
adamw well in YOUR case yes 17:02
adamw but the general bug... 17:02
adamw tflink: that doesn't seem hugely unlikely. 17:02
kparal the similar VNC bug was about usb NIC 17:02
adamw tflink: why wouldn't you write a kickstart locally that uses remote packages? that's what i do every time i test anything to do with kickstarts... 17:03
adamw oh, hm, well, i suppose 17:03
nirik anyhow, I guess I would lean toward -1/+1 barring info that the problem is widespread. 17:03
kparal of course the workaround is to server the kickstart over the net 17:03
adamw yeah, thinking about the use cases for really _local_ kickstart / remote packages, -1/+1 17:03
kparal then the net is active by the time it reaches anaconda 17:03
kparal I'm also -1/+1 17:04
Martix -1/+1 17:04
Martix fix it as NTH or document it 17:04
tflink proposed #agreed 892669 - RejectedBlocker AcceptedNTH - The combination of install media w/ embedded ks, no packages and slow network startup is too much of a corner case to block release over. However, a tested fix would be considered for pulling before release. 17:05
adamw man, the commonbugs for f18 is going to break records 17:05
adamw ack 17:05
Viking-Ice aaaccckkkk 17:05
kparal ack 17:06
tflink proposed #agreed 892669 - RejectedBlocker AcceptedNTH - The combination of install media w/ embedded ks, no packages and slow network startup is too much of a corner case to block release over since reasonable workarounds exist (add packages to media, use remote ks). However, a tested fix would be considered for pulling before release. 17:06
kparal adamw: we're just better at documenting :) 17:06
* tflink assumes that the acks didn't change w/ edit 17:06
tflink #agreed 892669 - RejectedBlocker AcceptedNTH - The combination of install media w/ embedded ks, no packages and slow network startup is too much of a corner case to block release over since reasonable workarounds exist (add packages to media, use remote ks). However, a tested fix would be considered for pulling before release. 17:07
Martix ack 17:07
tflink #topic (892046) IndexError: list index out of range 17:07
tflink #link https://bugzilla.redhat.com/show_bug.cgi?id=892046 17:07
tflink #info Proposed Blocker, anaconda, NEW 17:07
Viking-Ice kparal, we wish in truth we have double amount of issues this release cycle ;( 17:07
tflink it might be more than double if you're counting proposed blocker/nth bugs 17:07
Viking-Ice that's another btrfs/crash related one 17:08
adamw this specific one i'm -1/+1 on 17:08
adamw well, -1/weak +1... 17:08
tflink is this about the btrfs subvol size or booting from btrfs? 17:08
adamw i'm _reasonably_ sure this crash happens if you con anaconda somehow into creating a btrfs volume that's way too small 17:08
Viking-Ice at this point in time anaconda should not be crashing 17:09
adamw in other words, if you hit this crash, you're probably doing something you didn't want to be doing anyway 17:09
Viking-Ice it should just handle it gracefully 17:09
adamw yeah, that's never ever happened. 17:09
Viking-Ice anaconda handling something gracefully true that ;) 17:09
tflink -1/+1 17:09
Martix btrfs volumes smaller than 8 GB are problematic 17:09
Martix -1/+1 17:09
Viking-Ice -1/+1 17:10
adamw oh, hum, looks like my description was wrong 17:10
adamw sorry, i missed https://bugzilla.redhat.com/show_bug.cgi?id=892046#c17 17:10
adamw people may want to read that and re-vote, but i'm still -1/+1 i think 17:11
Viking-Ice well I'm more leaning towards +1/+1 17:11
tflink proposed #agreed 892046 - RejectedBlocker AcceptedNTH - This only occurs when doing something that you probably don't want to do in custom partitioning (in this case, creating btrfs subvols smaller than the minimum size) so it isn't enough to be a blocker. However, a tested fix would be considered for inclusion before release. 17:12
adamw yeah...it puts me closer to a +1. we're kinda hitting imponderables at this point (how many people are going to be installing over an existing btrfs install) 17:12
nirik isn't there a 'no crashing' critera? 17:12
Viking-Ice yes there is 17:12
tflink yeah, from beta 17:12
Viking-Ice and this hit's that 17:12
kparal actually there is no no crashing criterion for valid use cases, just for invalid ones :) 17:13
tflink "Rejecting obviously invalid operations without crashing" 17:13
nirik "The installer's custom partitioning mode must be capable of the following:" 17:13
nirik yeah 17:13
Viking-Ice "If I do not enter a capacity value, I don't get a crash." 17:14
* nirik is a weak +1/+1 I guess. Perhaps a fix would be to remove the size options from btrfs subvolumes? perhaps thats not too invasive? 17:14
Martix https://btrfs.wiki.kernel.org/index.php/FAQ#if_your_device_is_small 17:14
adamw remember, we weren't happy with those criteria and i was supposed to rewrite them, which i never got around to 17:14
adamw but yeah, this does kind of hit that. 17:14
tflink it sounds like we're more -1 blocker overall, though 17:15
Martix btrfs deal badly with volumes under <4GB, document it or add some limit 17:16
* tflink is not strongly -1, though 17:16
* adamw asking anaconda team for input 17:16
adamw Martix: no, this doesn't appear to be about (or not only about) size 17:16
Martix -1/+1 17:16
adamw see https://bugzilla.redhat.com/show_bug.cgi?id=892046#c17 17:16
nirik it's trying to specify a size on a btrfs subvolume... 17:17
nirik which... makes no sense. 17:17
Martix adamw: he is right 17:17
rbergeron does it crash if it has a reasonably sized volume specified? 17:17
nirik if you leave the size blank it does not crash 17:17
rbergeron (despite it not maing sense) 17:17
adamw nirik: it's not *just* that though 17:17
nirik my understanding is any value in there would cause a crash... 17:18
Martix nirik: ok 17:18
adamw nirik: as if you're creating a new layout from scratch, and you create multiple btrfs mount points and specify a size each time, it doesn't crash 17:18
rbergeron yeah, i saw, i just suspect that a lot of human behavior is to "fill in a box with a size if it asks for one" 17:18
nirik adamw: true. 17:18
adamw instead it applies the value you enter as the size of the volume 17:18
nirik it's only in the reuse case. 17:18
Martix document it, or better grey it out for subvolumes 17:18
adamw which is also kind of wacky, but at least not a crash 17:18
* nirik is more weakly blocker then... 17:19
adamw i'm not 100% sure we have this one entirely nailed down, which doesn't help evaluate it :/ 17:19
tflink continue with proposed #agreed and re-rpropose as blocker if something changes? 17:19
adamw the agreed needs patching anyway as this doesn't seem to be to do with smallness 17:20
nirik tflink: I'd be ok with that. 17:20
adamw brb, gotta go get a package from downstairs 17:20
maxamillion .... never fails, $dayjob gets insanely busy during this meeting ... the universe just doesn't like me to participate :/ 17:20
tflink proposed #agreed 892046 - RejectedBlocker AcceptedNTH - This only occurs when doing something that you probably don't want to do in custom partitioning (in this case, specifying size for a btrfs subvol instead of a quota) so it isn't enough to be a blocker. However, a tested fix would be considered for inclusion before release. 17:21
tflink did I understand correctly? 17:21
Martix ack 17:21
Viking-Ice ack 17:22
rbergeron ack 17:23
nirik sure, ack 17:23
tflink #agreed 892046 - RejectedBlocker AcceptedNTH - This only occurs when doing something that you probably don't want to do in custom partitioning (in this case, specifying size for a btrfs subvol instead of a quota) so it isn't enough to be a blocker. However, a tested fix would be considered for inclusion before release. 17:23
* tflink is skipping the proposed blockers that are already accepted NTH and VERIFIED 17:23
adamw ack for now 17:23
tflink #topic (892196) Anaconda cannot create new subvols on an existing multi-disk btrfs volume (works for single-disk btrfs volumes) 17:24
tflink #link https://bugzilla.redhat.com/show_bug.cgi?id=892196 17:24
tflink #info Proposed Blocker, anaconda, NEW 17:24
Viking-Ice tflink, you are following http://qa.fedoraproject.org/blockerbugs/milestone/18/final/bug list right ? 17:24
Viking-Ice did we not forget 892621 17:25
tflink Viking-Ice: kind of, there was a request to change the order up 17:25
Viking-Ice from whom and to what benefit 17:25
tflink Viking-Ice: we did that one first 17:25
Viking-Ice and by order up you mean what exactly ? 17:25
tflink do the highest priority ones first 17:25
adamw so this kinda sucks for existing multi-disk btrfs volumes, but it's existing multidisk btrfs volumes. 17:26
adamw i'm not sure we want to block on that at this point. 17:26
Viking-Ice  ? and who determines that priority 17:26
Martix Viking-Ice: ~chair 17:27
Martix adamw: +1 NTH 17:27
Viking-Ice in anycase the list there and how it's presented to participants needs to be the one and the same ( and in the same order ) 17:27
tflink Viking-Ice: there were no objections to changing the order at the time, it seemed to be the most obvious blocker at this point (judgement call) 17:27
adamw can we just discuss the bug? 17:28
tflink yeah, I'm thinking -1/+1 as well 17:28
Viking-Ice yeah sure 17:28
Viking-Ice -1/+1 17:28
tflink proposed #agreed 892196 - RejectedBlocker AcceptedNTH - This is rather nasty for people who have multi-disk btrfs volumes but it seems like too much of a corner case to block release over. However, a tested fix would be considered for inclusion before release. 17:29
adamw ack 17:29
nirik ack 17:29
kparal ack 17:30
tflink #agreed 892196 - RejectedBlocker AcceptedNTH - This is rather nasty for people who have multi-disk btrfs volumes but it seems like too much of a corner case to block release over. However, a tested fix would be considered for inclusion before release. 17:30
Martix ack 17:30
tflink #topic (875291) custom partitioning loses focus 17:30
tflink #link https://bugzilla.redhat.com/show_bug.cgi?id=875291 17:30
tflink #info Proposed Blocker, anaconda, NEW 17:30
kparal I have reported the dupe here, and it's damn easy to hit 17:31
Viking-Ice +1 nth 17:31
adamw at least nth 17:31
adamw i think this is the one dlehman was planning to work around somehow right? 17:31
jreznik_n9 and fixable, only worst user exp 17:32
kparal basically you enter custom partitioning twice and you are likely to find everything "stuck" 17:32
jreznik_n9 adamw, clumens 17:32
kparal very likely 17:32
adamw how ugly is the 'fix'? 17:32
adamw guess i can try it. 17:32
tflink I think it's more of a graphical thing 17:32
tflink the ugliness, I mean 17:32
adamw i meant ugly as in, well, ugly. 17:32
adamw graphically. 17:32
tflink ah, nvm then 17:32
jreznik_n9 better than non working 17:33
kparal adamw: create some partitions and then go back to hub and back to custom mode 17:33
Viking-Ice jreznik_n9, I dont think we need to concern ourselfs with Anaconda user experience it's horrible as is and it wont get any better 17:33
tflink definitely +1 NTH, slight +1 blocker 17:33
Viking-Ice jreznik_n9, we should just focus on breakage instead 17:33
Viking-Ice I'm slight +1 blocker as well 17:33
jreznik_n9 Viking-Ice, agreed 17:33
jreznik_n9 on breakage 17:33
Viking-Ice jreznik_n9, the amount of reports against anaconda gives a clear indication of the user experience people have with it ( I'm not talking about poorly designed UI here ) 17:35
kparal +1 blocker 17:35
* kparal trying the updates.img 17:36
Martix Viking-Ice: we can revisit Anaconda UX during F19 prealpha :-) 17:36
tflink thoughts on criterion? 17:36
Viking-Ice counting +3 blocker here 17:36
adamw i'm not sure it really hits criteria, hence -1 blocker narrowly 17:36
adamw if anyone can come up with a criteria fudge though, go for it :) 17:36
adamw +1 nth for sure 17:36
Martix -1 blocker/+1 NTH 17:36
tflink adamw: I think that's splitting hairs - it could prevent install unless the user is aware of the bug 17:37
tflink "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:37
Southern_Gentlem tflink, then document it 17:37
Martix we can document it, but I hope that new updates.img fixed that 17:37
Viking-Ice good enough criteria for me 17:37
Martix *fixes 17:37
tflink the "fudge" being: partitioning can't be completed if the window loses focus 17:38
kparal the update.img seems to work 17:38
adamw tflink: really? aren't they just gonna try again till it works? 17:38
adamw nothing irreversible has happened at this point and it's not a showstopper, they could just reboot and try again 17:38
tflink point 17:38
adamw i'm still -1, but i won't fight a +1. 17:39
tflink I'm about the opposite - slightly +1, but won't fight a -1 17:39
Viking-Ice me to 17:39
Martix we have *fix* 17:39
jreznik_n9 -1/+1 nth and strong nth 17:39
Viking-Ice in anycase it seems to be fixed 17:39
* nirik is slight -1, +1 17:39
tflink ok, sounds like -1 overall 17:39
Viking-Ice fine nth let's pull in the fix 17:39
tflink slightly 17:39
Martix Viking-Ice: I was writing the same 17:40
adamw well, there is still a difference: if it's NTH, and the fix causes other problems, we can just pull the fix and release 17:40
adamw if it's blocker, we'd be committed to 'fixing the fix' 17:40
tflink proposed #agreed 875291 - RejectedBlocker AcceptedNTH - While this does cause problems during installation, it doesn't do any irreversable changes to the system and thus, is not a blocker for F18 final. However, a tested fix would be considered for inclusion before release. 17:40
jreznik_n9 ack 17:41
Viking-Ice ack 17:41
kparal ack 17:41
tflink #agreed 875291 - RejectedBlocker AcceptedNTH - While this does cause problems during installation, it doesn't do any irreversable changes to the system and thus, is not a blocker for F18 final. However, a tested fix would be considered for inclusion before release. 17:41
tflink OK, that's all the proposed blockers that I see on my list 17:41
adamw ack (for the record) 17:41
Martix ack 17:41
nirik ack 17:41
kparal ack 17:42
tflink  ? 17:42
kparal heh 17:42
Martix finaly all #agreed :-) 17:42
tflink are there any NTH that need to be discussed today? I haven't read through the list today 17:43
Viking-Ice do we walk through these *DE trackers ? 17:43
tflink Viking-Ice: not sure what you mean, the bugs blocking the trackers are pulled in 17:43
tflink the trackers themselves are not supposed to show up on the list but that's a bug in the blockerbug webapp 17:44
Viking-Ice tflink, ah that's what was confusing me 17:44
adamw yeah, we just ignore them 17:44
Viking-Ice both the kde and xfce trackers are there 17:44
Martix ok, another blockerbug againts blockerbug app :-D 17:44
adamw once we have an RC that's acceptable and no bugs block the tracker, we can close the tracker 17:44
tflink I see 1 NTH that seems worth discussing 17:45
adamw shoot, then 17:45
tflink #topic (892120) Click on Cancel in confirm dialog for Quit on network setting, rebooting system 17:45
tflink #link https://bugzilla.redhat.com/show_bug.cgi?id=892120 17:45
tflink #info Proposed NTH, anaconda, POST 17:45
Viking-Ice +1 nth 17:46
Martix we have patch 17:46
kparal trivial fix probably 17:46
kparal +1 nth 17:47
Martix +1 nth 17:47
adamw +1 so long as the fix is really safe 17:47
* adamw readdy adverse to tinkering at this point 17:47
tflink proposed #agreed 892120 - AcceptedNTH - This shouldn't happen, can't be fixed with an update post-release and sounds like a reasonable, low-risk fix. Once tested, it would be considered for inclusion before release. 17:48
Martix ack 17:48
kparal ack 17:48
Viking-Ice ack 17:48
adamw ack 17:48
tflink #agreed 892120 - AcceptedNTH - This shouldn't happen, can't be fixed with an update post-release and sounds like a reasonable, low-risk fix. Once tested, it would be considered for inclusion before release. 17:48
tflink another one that I'm pretty sure is -1 nth but is worth discussing in case I'm missing something 17:49
tflink #topic (886685) grub2 fails to boot when /boot partition is lvm on multipath device 17:49
tflink #link https://bugzilla.redhat.com/show_bug.cgi?id=886685 17:49
tflink #info Proposed NTH, grub2, ON_QA 17:49
tflink as much as I think ppc needs this, I'm -1 NTH 17:49
tflink don't want to be mucking around with grub this late 17:49
adamw ppc is a secondary arch build so they can pull it themselves, i believe 17:49
adamw they aren't committed to the frozen package set 17:49
adamw at this late stage, -1, no fiddling with grub2. 17:50
tflink oh, was this pulled into the list due to a tracker? 17:50
Southern_Gentlem -1 17:50
Viking-Ice -1 17:50
tflink nope, it was proposed nth 17:50
adamw this doesn't look at all ppc-specific, but it is multipath-specific. i think. 17:50
* rbergeron suspects lots of cluster folks do this as well ... can see if she can get someone from that land to pipe in 17:50
adamw rbergeron: they'd probably be fine installing from network repos, right? 17:51
tflink proposed #agreed 886685 - RejectedNTH - This seems to mostly affect ppc which can pull in pkgs outside the PA blocker process. This is too risky to pull in as NTH for F18 and thus, rejected as NTH. 17:51
Viking-Ice rbergeron, does not change the fact that at this point touching anything that touches grub2 is ill adviced ;) 17:51
rbergeron adamw: yes 17:51
Viking-Ice ack 17:51
tflink proposed #agreed 886685 - RejectedNTH - This seems to mostly affect ppc which can pull in pkgs outside the PA blocker process. This is too risky to pull in as NTH for F18 this late and thus, rejected as NTH. 17:51
rbergeron Viking-Ice: I know it ;) 17:51
tflink s/for F18/for F18 this late/ 17:52
adamw patch, i don't see anything ppc-specific. 17:52
jreznik_n9 ack 17:52
tflink was the change 17:52
adamw i'd talk about multipath not ppc. 17:52
adamw well 17:52
adamw oh, actually, maybe it is 17:52
adamw 'ieee1275' seems to be OpenFirmware, which is a ppc64 thang, i guess. 17:52
tflink proposed #agreed 886685 - RejectedNTH - This only affects multipath installs which aren't believed to be incredibly common on primary arch (more common on ppc). Secondary arches can pull in pkgs outside the PA blocker process and a fix for this bug isn't critical. This is too risky to pull in as NTH for F18 this late and thus, rejected as NTH. 17:53
tflink proposed #agreed 886685 - RejectedNTH - This only affects multipath installs which aren't believed to be incredibly common on primary arch (more common on ppc). Secondary arches can pull in pkgs outside the PA blocker process and a fix for this bug isn't critical for PA. This is too risky to pull in as NTH for F18 this late and thus, rejected as NTH. 17:53
tflink better? 17:54
adamw sorry, i'm confusing things 17:54
adamw no 17:54
adamw lemme try 17:54
tflink I'd argue that it may not be ppc-specific but the reports are all ppc 17:54
rbergeron yeah, that's not clear to me 17:54
tflink I'm not sure how many people are using /boot on multipath outside ppc 17:55
adamw proposed #agreed 866685 RejectedNTH - this only affects installs to LVM-on-multipath on OpenFirmware systems. OpenFirmware is mostly used on ppc64 systems, very rarely on i386/x86_64, though it is theoretically possible. Secondary arches can pull in pkgs outside the PA blocker process and a fix for this bug isn't critical for PA. This is too risky to pull in as NTH for F18 this late and thus, rejected as NTH. 17:55
adamw tflink: i don't see why it'd be particularly ppc people who use /boot on multipath. there's nothing specific to ppc about multipath. *but*, now i look at the patch, it seems to touch only hte OpenFirmware code in grub2, hence the above. 17:55
tflink yeah, I just looked at the patch 17:55
tflink this fix is openfirmware specific 17:55
tflink adamw: IIRC, most x86 systems don't use multipath for local storage (raid or not) 17:56
Viking-Ice  ? 17:56
tflink am I wrong? 17:56
Viking-Ice *cough* plethora of servers do *cough* 17:57
adamw tflink: well i mean define 'most' 17:57
adamw of course 'most' don't, but it's a perfectly valid config, isn't it? most x86 systems don't use multipath for anything at all. 17:57
tflink Viking-Ice: for local storage? 17:57
tflink local/internal raid 17:58
Viking-Ice yes 17:58
tflink I'm not talking about remote storage - I know that most servers use mp for remote storage 17:58
tflink huh, chalk that up to my experience being mostly with HP servers I guess 17:58
Viking-Ice oh then I'm misunderstanding 17:58
tflink either way, we're getting off topic 17:59
tflink ack 17:59
adamw tflink: yeah, even if you're right, i think my agreed stands 17:59
Viking-Ice ack 17:59
tflink adamw: it's easier if you do the #agreed - I'd rather not have to copy and re-format 18:00
adamw #agreed 866685 RejectedNTH - this only affects installs to LVM-on-multipath on OpenFirmware systems. OpenFirmware is mostly used on ppc64 systems, very rarely on i386/x86_64, though it is theoretically possible. Secondary arches can pull in pkgs outside the PA blocker process and a fix for this bug isn't critical for PA. This is too risky to pull in as NTH for F18 this late and thus, rejected as NTH. 18:00
* rbergeron belatedly acks 18:00
tflink any other NTHs? 18:01
tflink I take that as a no - I think we're done with blocker review for the day, then 18:02
Viking-Ice have we been through 892269 alraedy 18:03
tflink Viking-Ice: yes but it hasn't been updated yet 18:03
tflink acceptedNTH and rejectedblocker IIRC 18:03
* tflink checks logs 18:03
Viking-Ice tflink, ok 18:03
Viking-Ice adamw, did you check the comment in the bug I ping you with when I joined the meeting 18:04
adamw okay 18:04
adamw Viking-Ice: sorry, i think i missed that. what was it? 18:04
Viking-Ice "I've added a note on this pointing users to kickstart files, and the kickstart documentation in the Installation Guide. Thanks, J&#243;hann." 18:04
adamw was that about your action item from earlier? 18:05
Viking-Ice just an update to my task 18:05
adamw ah ok, cool 18:05
adamw i'll update that in open floor 18:05
adamw poke me if i forget 18:05
adamw #topic Fedora 18 Final status / planning 18:05
adamw so outside of blocker review, any thoughts on f18 status? 18:05
tflink Viking-Ice: actually, you voted on 892269, no? The discussion blended in to 892494 and the transition wasn't incredibly obvious 18:05
tflink I have one item that could either be final planning or open floor 18:06
adamw may as well fire it now 18:06
tflink when should documentation be updated - I'm going to be updating FedUp documentation today and if I write it for final, people following it now won't get expected results 18:07
tflink I'm talking about the main wiki page, not the testing docs 18:07
adamw maybe hold it as a draft until the day or two before release? 18:07
Viking-Ice tflink, I sometime loose track half in dayjob half in meeting 18:07
tflink http://fedoraproject.org/wiki/FedUp 18:07
tflink Viking-Ice: no worries, just offering an explanation on why it might have been missed 18:08
tflink I suppose that works for me - hold off on updating the release-dependant stuff until a day or two before release 18:09
Viking-Ice yeah that might be best 18:09
adamw have it as a draft in your personal space or whatever 18:10
adamw so you can just copy/paste it in, a day or two before release 18:10
tflink yep, that'll work 18:10
tflink I'll update the testing docs first, then merge the changes in 18:10
tflink part of this is deduping some information but I digress 18:11
tflink the only other thing I'd like to mention is to be careful about the URL if/when testing fedup 18:12
adamw what's the good word? 18:13
tflink the URL in the test case was wrong until an hour or two ago 18:13
tflink then again, it was wrong when initially authored, so I'm not sure how many people have run through it 18:13
adamw what's the good URL? 18:14
tflink http://dl.fedoraproject.org/pub/fedora/linux/development/18/<arch>/os/ 18:14
tflink where <arch> is either i386 or x86_64 18:15
adamw that's for --instrepo ? 18:15
tflink yep 18:15
adamw #info use --instrepo http://dl.fedoraproject.org/pub/fedora/linux/development/18/<arch>/os for testing fedup 18:15
tflink if there is any question about what the latest version is, ask me 18:16
tflink the process of getting the upgrade.img updated isn't 100% straight forward but I don't expect any changes before release 18:17
kparal tflink: what are the news about fedup gui? 18:17
kparal the last time I checked, the GUI disappeared from the fedora package 18:18
tflink it'll be after F18 18:18
tflink fesco decided that it wasn't a release-blocking issue 18:19
adamw okay, so i guess our plan now is to try and knock out an RC2 and get it tested today 18:19
kparal ok 18:19
adamw anyone have any other f18-specific concerns 18:19
tflink other than getting it out the door? :-P 18:19
adamw jreznik_n9: when is go/no-go scheduled again? 18:19
tflink the only thing on my mind would be to make sure that the blocker review meeting isn't scheduled for the same time or after go/no-go 18:19
Viking-Ice we should not be releasing F18 with Anaconda and Fedup in this shape but meh I give up trying to get some common sense into people 18:21
adamw according to the schedule page right now, it's wednesday at 1700 est 18:21
adamw so i guess if we want to do antoher blocker review outside of that, tomorrow or wed morning 18:21
tflink so a couple hours after blocker review 18:21
tflink er, the time we usually use for blocker review 18:22
tflink I'm thinking play it by ear until then. plan for the normal time on wednesday, move it to tomorrow if it seems needed 18:22
adamw okay 18:22
adamw #info next blocker review currently scheduled for wednesday, may move up to tomorrow if needed (more blockers emerge today) 18:23
adamw time to get crackin', I guess 18:23
adamw #topic open floor 18:23
adamw #info follow-up: "viking-ice to let docs team know about advanced storage for release notes" - this was done, install guide points advanced storage users to kickstart 18:24
* Viking-Ice turns the lighter on and light the fuse muhahaha 18:26
adamw anything else for open floor? 18:26
adamw my god, that was the wrong fuse 18:26
adamw that's the one connected to the bomb under canonical HQ 18:26
tflink nothing from me 18:26
Viking-Ice adamw, try calling for help using the triple U phone 18:27
adamw Viking-Ice: let's see...progress bar...looks like it'll complete the call some time in 2018 18:27
Viking-Ice we will all be using flying hoverboards by that time ;) 18:28
adamw okey dokey, looks like it's time to get on with f18 testin' 18:28
adamw thanks for coming everyone! 18:28
adamw #endmeeting 18:29

Generated by irclog2html.py 2.11.0 by Marius Gedminas - find it at mg.pov.lt!