From Fedora Project Wiki

< QA‎ | Meetings

Revision as of 02:23, 16 November 2011 by Adamwill (talk | contribs) (create page (catching up with the last two months of meetings, bad me))
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)

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!