From Fedora Project Wiki
Attendees
- adamw (132)
- kparal (32)
- tflink (25)
- red_alert (12)
- pjones (9)
- jsmith (6)
- maxamillion (6)
- zodbot (5)
- jskladan (4)
- pschindl (3)
- Southern_Gentlem (2)
- robatino (2)
- brunowolff (1)
- Cerlyn (1)
- jwb (1)
Agenda
Previous meeting follow-up
- x86_64 ISO generation for TC1 got done
- Kernel team was made aware of the final freeze date
Fedora 16 Final preparation
- Final RC1 was planned for the day after the meeting
- The rest of the meeting became a blocker review meeting, see the log for details
IRC Log
adamw | #startmeeting Fedora QA Meeting | 15:02 |
---|---|---|
zodbot | Meeting started Mon Oct 24 15:02:00 2011 UTC. The chair is adamw. Information about MeetBot at http://wiki.debian.org/MeetBot. | 15:02 |
zodbot | Useful Commands: #action #agreed #halp #info #idea #link #topic. | 15:02 |
* pschindl is here | 15:02 | |
adamw | #meetingname fedora-qa | 15:02 |
zodbot | The meeting name has been set to 'fedora-qa' | 15:02 |
pschindl | good morning Adam | 15:02 |
adamw | damnit, no talking before I set meetingname! :) | 15:02 |
* jskladan lurks in | 15:02 | |
adamw | hey pschindl | 15:02 |
adamw | #chair kparal | 15:02 |
zodbot | Current chairs: adamw kparal | 15:02 |
adamw | #topic roll call | 15:02 |
* jsmith lurks | 15:02 | |
adamw | who's around? | 15:02 |
* tflink is here | 15:02 | |
* adamw takes out a can of ACME Jsmith Repellent | 15:02 | |
* pschindl still here | 15:02 | |
* kparal is here | 15:02 | |
tflink | adamw: wow, you made jsmith go away | 15:04 |
* red_alert is here | 15:04 | |
adamw | hey, that stuff really works! | 15:04 |
* adamw points to ACME-branded product and grins at the camera | 15:04 | |
* Cerlyn is here | 15:05 | |
adamw | alrighty, let's get this show on the road | 15:05 |
adamw | #topic previous meeting follow-up | 15:05 |
adamw | #chair tflink | 15:05 |
zodbot | Current chairs: adamw kparal tflink | 15:05 |
adamw | this is the part of the show where we find out what adam forgot to do last week! | 15:05 |
* maxamillion is here | 15:05 | |
adamw | "adamw to check with dgilmore where we are with x86_64 iso generation" | 15:06 |
adamw | welp, that got done | 15:06 |
adamw | (we eventually got x64 isos for TC1, and we got 'em on day 1 for TC2) | 15:06 |
adamw | aw, man, the jsmith came back | 15:07 |
adamw | "action adamw to co-ordinate with kernel team for final release build" | 15:07 |
jsmith | adamw: You can't get rid of me that easily.... | 15:07 |
adamw | i did make 'em aware of the freeze date | 15:07 |
adamw | i'll check back in with them today to see what they're planning | 15:07 |
jsmith | There were plenty of announcements regarding the change freeze | 15:07 |
jwb | adamw, Chuck submitted the 3.1 final build to updates this morning | 15:07 |
adamw | jwb: awesome | 15:08 |
adamw | jsmith: yeah, but the personal touch always helps. | 15:08 |
adamw | okay, moving on | 15:11 |
adamw | #topic Fedora 16 Final preparation | 15:11 |
adamw | so we're aiming for RC tomorrow, which means we have a busy day's blocker squashin' coming up today | 15:11 |
robatino | http://rbergero.fedorapeople.org/schedules/f-16/f-16-quality-tasks.html still says the 26th | 15:12 |
robatino | 57. Test 'Final' RC Wed 2011-10-26 Tue 2011-11-01 6 | 15:12 |
adamw | that's when we *test* it | 15:13 |
adamw | http://rbergero.fedorapeople.org/schedules/f-16/f-16-releng-tasks.html says it gets composed tomorrow | 15:14 |
brunowolff | For the past topic, release kernel builds were done this monring. Unfortunately I had to leave for work before they fimished, but I'll be rebooting my work machine in a few minutes. (Before I head to a work meeting.) | 15:14 |
adamw | ah, and 'delivered' on 26th, so either someone thought we used fedex for rcs, or releng gets a whole day to build it. =) | 15:14 |
adamw | anyhoo | 15:14 |
adamw | let's do the blocker dance... | 15:14 |
adamw | let's not spend too much of this meeting on accepted blockers, but we have 6 proposed blockers to look at | 15:15 |
adamw | #topic https://bugzilla.redhat.com/show_bug.cgi?id=747318 | 15:15 |
adamw | charles claims to see this one on boot of tc2 live desktop; it does seem like a lot of people hit it, but i haven't yet on either of my systems | 15:16 |
tflink | yeah, I haven't seen that in a week or so on my installed F16 | 15:16 |
adamw | i am worried at the number of people hitting it though | 15:17 |
kparal | according to our criteria seems like a blocker | 15:18 |
kparal | the question is how hard it will be to debug | 15:18 |
red_alert | some people seem to even hit it by merely booting the livecd :/ | 15:18 |
kparal | can we somehow tell whether they are using gnome shell or fallback? | 15:19 |
* adamw wonders if http://git.gnome.org/browse/gnome-settings-daemon/commit/?id=a33a74840f55e2d5e844f7491c27e23ff42c36c0 is the fix | 15:19 | |
adamw | well, if it happens to some people but not all on a simple 'boot / use', then it becomes a judgement call, but yeah, seems like enough people hit it to make it a +1 | 15:20 |
adamw | propose #agreed 747318 is a blocker under criterion "In most cases, there must be no SELinux 'AVC: denied' messages or abrt crash notifications on initial boot and subsequent login (see Blocker_Bug_FAQ)" | 15:22 |
tflink | ack | 15:22 |
kparal | ack | 15:22 |
red_alert | ack | 15:22 |
jskladan | ack | 15:22 |
adamw | #agreed 747318 is a blocker under criterion "In most cases, there must be no SELinux 'AVC: denied' messages or abrt crash notifications on initial boot and subsequent login (see Blocker_Bug_FAQ)" | 15:23 |
adamw | i'm poking desktop about it atm | 15:23 |
adamw | meanwhile... | 15:23 |
adamw | #topic https://bugzilla.redhat.com/show_bug.cgi?id=743273 | 15:23 |
kparal | I don't know much about RAIDs. Does Jen have a different RAID than you or pjones has? | 15:25 |
tflink | so neither adamw nor pjones can repro this? | 15:25 |
adamw | i just added a comment to thus | 15:26 |
adamw | i think jes' latest test is clearly broken | 15:26 |
pjones | He just added some more stuff to it | 15:26 |
pjones | so apparently it has to be a raid1 and it has to be dirty | 15:26 |
pjones | which... I just don't know, I'm going to look at it more this afternoon and see if there's even anything we can do there. | 15:26 |
adamw | pjones: see my comment. i don't think his test could possibly have worked. he installed the bootloader to /boot then tried to boot straight from that disk. it's not going to fly. | 15:27 |
adamw | (unless i'm misunderstanding something) | 15:27 |
adamw | wdyt? | 15:28 |
pjones | I think it's pretty ingenuous to tell him "of course that's not going to work, do this other thing" when the other thing is something it won't let him do... | 15:29 |
tflink | pjones: won't the other thing work in TC2? | 15:29 |
adamw | pjones: hum? it should | 15:29 |
pjones | is he testing with an old tree or something, then? | 15:30 |
adamw | he *said* beta tc1, which is old as the hills | 15:30 |
tflink | according to his comment, Beta-TC1 | 15:30 |
adamw | even if he *meant* final tc1, it changed in tc2 | 15:30 |
adamw | see https://bugzilla.redhat.com/show_bug.cgi?id=744088 | 15:30 |
adamw | that was fixed in anaconda 16.22, i.e., tc2 | 15:30 |
pjones | okay, so we need him to test with a newer tree. | 15:31 |
pjones | can somebody tell him where to find that tree? | 15:31 |
adamw | will update. | 15:32 |
adamw | anyhow, ideally we'd want to punt on this, but...i think pjones is thinking that even if it was valid it might not be a blocker? | 15:33 |
pjones | well, it might be that in this situation you need to go into imsm and say "hey, fix the damned disk" before you continue. | 15:33 |
pjones | but I say "might" on purpose; I'll know more this PM | 15:34 |
adamw | okay | 15:34 |
adamw | we can punt till this afternoon at least | 15:34 |
adamw | propose #agreed 743273 is looking like a corner case and/or pilot error, but pjones hopes to know more this afternoon, so leave it until then | 15:34 |
tflink | ack | 15:35 |
* kparal abstains | 15:35 | |
* adamw gets the ACME brand abstain remover | 15:35 | |
kparal | ack | 15:36 |
red_alert | ack | 15:36 |
jsmith | ack | 15:36 |
adamw | #agreed 743273 is looking like a corner case and/or pilot error, but pjones hopes to know more this afternoon, so leave it until then | 15:36 |
adamw | #topic https://bugzilla.redhat.com/show_bug.cgi?id=747982 | 15:37 |
adamw | seems pretty straightforward +1 to me | 15:37 |
adamw | and it has a fix already, my favourite kind of blocker! | 15:37 |
tflink | +1 | 15:37 |
* kparal never used KDE 4, but AFAIUI it should be a blocker | 15:38 | |
adamw | propose #agreed 747982 is a blocker per criterion "All elements of the default panel configuration in all release-blocking desktops must function correctly in common use" | 15:40 |
red_alert | ack | 15:40 |
tflink | ack | 15:41 |
kparal | ack | 15:41 |
jskladan | ack | 15:41 |
adamw | #agreed 747982 is a blocker per criterion "All elements of the default panel configuration in all release-blocking desktops must function correctly in common use" | 15:42 |
adamw | #topic https://bugzilla.redhat.com/show_bug.cgi?id=748344 | 15:42 |
adamw | so...this one's clearly *wrong*, but then, it's been that way forever. we shipped f15 like this and nothing exploded. | 15:42 |
adamw | it causes the live image to do a few things it shouldn't when booted EFI, but...i'm not convinced it's a blocker. | 15:42 |
kparal | it's just minor annoyance, but nothing horrible, right? | 15:43 |
kparal | or can it cause some problems? | 15:43 |
tflink | adamw: live images on USB, right? It sounds like syslinux does this properly | 15:43 |
adamw | it can cause problems, yeah, that's why we put those parameters in boot usually | 15:43 |
adamw | what they do is stop dracut trying to mount raid arrays and encrypted volumes that it finds on the system when booting live | 15:43 |
adamw | i think it can cause anaconda a few issues, and also, you might be booting live on a system which has an encrypted partition whose password you don't know... | 15:44 |
adamw | but i don't think it's really serious enough to make a blocker, overall. efi is still a pretty niche pursuit. | 15:44 |
kparal | I don't have overall idea what can go wrong, but otherwise I agree it seems not serious enough | 15:45 |
tflink | and you can work around in many cases by using a DVD/CD | 15:45 |
kparal | on the other hand, we can't fix this post-release | 15:45 |
kparal | or actually we can | 15:46 |
kparal | by updating livecd-to-disk tool | 15:46 |
tflink | yeah | 15:46 |
kparal | ok, severity-- | 15:46 |
adamw | i think i'm +1 nth, -1 blocker on this one | 15:46 |
adamw | yeah, the update scenario is a point too | 15:46 |
kparal | agreed from me | 15:47 |
tflink | -1 blocker, +.5 NTH | 15:47 |
red_alert | -1 blocker, +1 NTH | 15:48 |
adamw | oh, yeah, update scenario does affect nth | 15:48 |
adamw | so...i think i'm -1 / -1 in that case, there's nothing to fix in the images themselves here | 15:48 |
kparal | but nth can be used to have fixed livecd-iso-to-disk in the final release | 15:49 |
Southern_Gentlem | so file a bugzilla on livecd-tools now | 15:49 |
kparal | but it doesn't really that much, I agree | 15:49 |
adamw | livecd-tools isn't even installed by default i don't think | 15:49 |
tflink | kparal: I don't think that livecd-to-iso is on the DVD, is it? | 15:49 |
kparal | *help | 15:49 |
adamw | Southern_Gentlem: this bug's already against livecd-tools | 15:49 |
adamw | so... | 15:50 |
adamw | propose #agreed 748344 rejectedblocker rejectednth: the impact of this one when you combine EFI plus RAID or encrypted partitions is small, and the fix is not on the image but in the image creation tool, so can be done safely as an update | 15:51 |
kparal | tflink: it seems they are not on DVD | 15:51 |
tflink | ack | 15:51 |
kparal | ack | 15:51 |
Southern_Gentlem | wrong http://mirror.cc.vt.edu/pub/fedora/linux/development/16/i386/os/Packages/livecd-tools-16.6-1.fc16.i686.rpm | 15:51 |
kparal | I was looking into the DVD.iso itself | 15:52 |
adamw | of course it's on mirrors. | 15:52 |
adamw | *everything's* on the mirrors. | 15:52 |
adamw | point is if we fix it as a 0-day update, there's no way you'd possibly get the release version from yum.\ | 15:53 |
adamw | so it doesn't matter whether the fix is in the release package set, or a 0-day update: either works equallty well. | 15:53 |
adamw | #agreed 748344 rejectedblocker rejectednth: the impact of this one when you combine EFI plus RAID or encrypted partitions is small, and the fix is not on the image but in the image creation tool, so can be done safely as an update | 15:54 |
adamw | #topic https://bugzilla.redhat.com/show_bug.cgi?id=744217 | 15:54 |
adamw | so, this seems like a mess | 15:54 |
kparal | more raid :/ | 15:55 |
adamw | well it's some fix dledford wants to get in | 15:55 |
adamw | but it seems to be a double clone so i've no idea where it ultimately comes from | 15:55 |
adamw | i really, really hate cloning. | 15:55 |
adamw | it could be somehow to do with the *other* remaining proposed blocker - https://bugzilla.redhat.com/show_bug.cgi?id=743022 - but i'm really not sure | 15:56 |
adamw | https://admin.fedoraproject.org/updates/mdadm-3.2.2-12.fc16 seems to describe the bugs pretty well, anyway | 15:57 |
adamw | based on those I'm +1 blocker under the RAID criterion or the 'workable partition layout' criterion | 15:58 |
adamw | seems like if your RAID array degrades Fedora will refuse to boot, which is not good. | 15:58 |
maxamillion | adamw: +1 | 15:58 |
red_alert | +1 blocker | 15:59 |
* jskladan needs to leave, see you around, gang! | 16:00 | |
* kparal agrees with anybody when raid is concerned | 16:01 | |
adamw | propose #agreed 744217 is a blocker under criterion "The installer must be able to create and install to software, hardware or BIOS RAID-0, RAID-1 or RAID-5 partitions for anything except /boot " combined with "Following on from the previous criterion, after firstboot is completed and on subsequent boots, a system installed according to any of the above criteria (or the appropriate Beta or Final criteria, when applying this criterion to those releases) | 16:01 |
adamw | must boot to a working graphical environment without unintended user intervention. This includes correctly accessing any encrypted partitions when the correct passphrase is supplied" | 16:01 |
jsmith | ACK | 16:01 |
tflink | this mostly affects unhealthy RAID arrays, no? | 16:01 |
adamw | yes. but, that's kind of the point of RAID. | 16:02 |
adamw | if your system is going to fail to boot if your RAID array degrades that rather negates the point of having a RAID array in the first darn place =) | 16:02 |
red_alert | ack | 16:02 |
tflink | oh? I thought that the point of RAID was not to lose data as easily w/ HW error | 16:02 |
adamw | tflink: well yeah. but this makes it much harder than it needs to be to actually recover your data. | 16:03 |
adamw | a 'degraded' RAID array is what you get when one of the disks actually fails. (or just hiccups). | 16:03 |
adamw | so what you usually do is swap out the failed disk and boot in the 'degraded' state, and the array then rebuilds itself. | 16:03 |
adamw | if Fedora fails to boot in the degraded state...you have to boot up some other thing just to get the array to recover. | 16:04 |
tflink | point | 16:04 |
tflink | ack | 16:04 |
adamw | #agreed 744217 is a blocker under criterion "The installer must be able to create and install to software, hardware or BIOS RAID-0, RAID-1 or RAID-5 partitions for anything except /boot " combined with "Following on from the previous criterion, after firstboot is completed and on subsequent boots, a system installed according to any of the above criteria (or the appropriate Beta or Final criteria, when applying this criterion to those releases) must bo | 16:05 |
adamw | ot to a working graphical environment without unintended user intervention. This includes correctly accessing any encrypted partitions when the correct passphrase is supplied" | 16:05 |
adamw | #topic https://bugzilla.redhat.com/show_bug.cgi?id=743022 | 16:06 |
adamw | so this one just seems stuck, and the devs don't care about it much | 16:06 |
adamw | given that, and the description is f15->f16 yum update, i think we can just reject it now | 16:06 |
adamw | if it was a more serious issue, dledford/jes would give more of a damn... | 16:07 |
tflink | if it's limited to yum upgrade, -1 blocker | 16:08 |
adamw | yeah, -1 here | 16:09 |
kparal | same from me | 16:09 |
kparal | nth +1? | 16:09 |
maxamillion | nth +1, blocker -1 | 16:10 |
adamw | not sure nth makes sense for a yum upgrade issue | 16:11 |
adamw | if you're doing a yum upgrade, you're getting updates | 16:11 |
tflink | yeah, maybe if it was all systems on yum upgrade | 16:11 |
kparal | ah, that's true | 16:11 |
red_alert | IMHO there has been progress from devs and jes sure was busy with the two RAID issues from before | 16:11 |
tflink | good point, I wasn't thinking about pulling in updates | 16:12 |
red_alert | (regarding "no one gives a damn") | 16:12 |
adamw | red_alert: sure, but they were busy with the other issue because they considered it more important | 16:12 |
adamw | which is kind of the point :) | 16:12 |
adamw | propose #agreed 743022 is not a blocker, only known to affect some yum upgrades, yum upgrade is not supported by the criteria | 16:13 |
adamw | let's get blocker status out of the way first | 16:13 |
tflink | ack | 16:14 |
red_alert | I thought blockers were about technical significance and not about priorities of reporters/devs | 16:14 |
kparal | ack | 16:14 |
jsmith | blockers are about release criteria | 16:14 |
red_alert | ack (-1 blocker +1 nth) | 16:14 |
adamw | red_alert: in this case, it's a good indication the bug isn't incredibly serious | 16:15 |
adamw | or else they'd have given it a higher priority | 16:15 |
adamw | propose #agreed 743022 is rejected NTH, as it affects yum upgrade, and when doing a yum upgrade, you'd always be pulling updates: so there's no benefit to pulling a fix through the freeze | 16:16 |
tflink | ack | 16:16 |
kparal | ack | 16:17 |
adamw | #agreed 743022 is rejected NTH, as it affects yum upgrade, and when doing a yum upgrade, you'd always be pulling updates: so there's no benefit to pulling a fix through the freeze | 16:17 |
adamw | okay, that's all the proposed blockers | 16:18 |
adamw | i think it'd be a bit of a waste to go through all the proposed NTH, but people can vote on them in the bugs | 16:19 |
adamw | https://fedoraproject.org/wiki/Current_Release_Blockers#Proposed_NICE-TO-HAVE is the list | 16:19 |
adamw | it'd be good to vote on all the modified/on_qa ones at least | 16:19 |
adamw | anyone have any other concerns for f16? | 16:19 |
adamw | #topic f16 final preparation | 16:20 |
adamw | well then, guess we can move on... | 16:21 |
adamw | do we have any news on the proventester or autoqa fronts? | 16:21 |
maxamillion | adamw: I noticed over the weekend that when I updated my kernel the new one didn't take default in grub2 | 16:21 |
maxamillion | I meant to follow up with that ... but was busy with homework so didn't get around to it | 16:22 |
* kparal has no autoqa update | 16:22 | |
adamw | maxamillion: noted...keep an eye on it | 16:22 |
maxamillion | adamw: will do, I'll go check and see if its been reported yet | 16:23 |
adamw | i haven't seen that, it always works for me | 16:23 |
adamw | #topic open floor | 16:23 |
adamw | so, any other business? | 16:23 |
adamw | in that case, thanks for coming, everyone | 16:26 |
adamw | #endmeeting | 16:26 |
Generated by irclog2html.py 2.8 by Marius Gedminas - find it at mg.pov.lt!