From Fedora Project Wiki
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
- Use --instrepo http://dl.fedoraproject.org/pub/fedora/linux/development/18/(arch)/os for testing fedup
- Next blocker review was scheduled for Wednesday, could move up to Tuesday if needed (more blockers emerged)
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ó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!